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ABSTRACT 


Currently  the  Naval  Postgraduate  School's  Alumni 
Database  houses  the  records  of  nearly  twenty-six  thousand 
alumni,  however  there  are  over  fifty  thousand  more  records 
that  need  to  be  added.  Although  a  database  currently 
exists  that  attempts  to  fulfill  many  of  the  requirements  of 
an  alumni  system,  it  has  been  determined  that  overall  the 
current  database  is  inadequate.  A  need  exists  to  either 
modify  or  replace  the  current  system  to  ensure  that  all  of 
the  Naval  Postgraduate  School's  alumni  relation  needs  are 
met.  A  decision  is  being  pondered  about  whether  the 
creation  and  management  of  such  a  system  should  be  done 
within  the  confines  of  the  school  or  outsourced  to  another 
organization,  this  thesis  will  aid  in  that  decision  making 
process.  Throughout  this  study,  evaluations  are  made  on 
the  feasibility  of  having  an  alumni  system,  and  the  most 
cost  effective  way  to  obtain  it.  Assessments  and 
recommendations  are  also  made  on  issues  involving  security, 
accessibility,  and  the  responsibilities  of  the  system' s 
users,  as  well  as  the  system.  In  its  entirety,  this  thesis 
will  serve  as  a  foundation  for  those  who  will  determine  how 
the  Naval  Postgraduate  School  will  proceed  in  finding  a 
solution  to  its  alumni  needs. 
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INTRODUCTION 


I . 


A .  BACKGROUND 

Established  in  1909,  the  Naval  Postgraduate  School 
began  as  a  small  graduate  school  specifically  designed  to 
educate  military  officers.  Through  its  transition  from 
Annapolis,  Maryland  to  Monterey,  California,  and  throughout 
its  existence  there  have  been  thousands  of  students  who 
have  matriculated  at  the  institution.  Since  most  of  these 
graduates  have  served,  or  will  continue  to  serve  in  many 
different  military  and  civilian  capacities,  therein  lays  a 
valuable  reservoir  of  knowledge  waiting  to  be  accessed. 
This  knowledge  is  important  to  the  Naval  Postgraduate 
School  for  several  reasons  that  range  from  conducting 
alumni  surveys  to  generating  ideas  and  answers  to  various 
research  issues.  Over  the  past  fifteen  years  various 
attempts  have  been  made  to  construct  a  way  to  access  this 
knowledge  and  to  stay  connected  with  the  graduates, 
however,  a  glaring  void  still  exists  in  this  arena. 

Currently,  there  is  no  effective  medium  that  exists 
that  allows  the  Naval  Postgraduate  School's  staff  and 
faculty  to  stay  connected  with  the  school's  alumni. 
Naval  Captain  Jeff  Kline  of  the  Graduate  School  of 
Operations  and  Information  Science,  Dean  Douglas  Brook  of 
the  Graduate  School  of  Business,  and  Naval  Commander  Sue 
Higgins,  a  faculty  member  in  the  Space  Systems  curriculum, 
agree  that  by  having  an  effective  system,  all  departments 
within  the  school  would  be  able  to  obtain  more  feedback  on 
real  world  issues  and  problems  that  dominate  the  business 
world,  as  well  as  the  fleet.  Dean  Brook  also  suggests  that 
tracking  how  well  the  school  is  progressing  as  a  learning 
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institution  would  also  be  easier  to  accomplish  with  a  more 
effective  system  available.  He  notes  that  although  some 
processes  may  be  accomplished  by  the  current  system,  the 
advantages  created  by  a  more  diverse  and  user-friendly 
system  would  be  nearly  limitless. 

Group  mail-outs  to  alumni  and  former  staff,  as  well  as 
daily,  weekly,  or  monthly  updates  of  the  changes  being  made 
at  the  school  would  also  be  an  activity  greatly  facilitated 
by  a  more  effective  system.  Presently  the  possibility  of 
these  updates  being  done  by  one  central  system  does  not 
exist,  however  they  are  being  attempted  through  various 
means  that  are  seen  by  only  a  small  fraction  of  its 
intended  audience.  With  a  new  and  more  effective  system, 
files  would  be  managed  and  maintained  electronically  which 
would  allow  for  greater  accessibility,  usability,  and 
visibility . 

Additionally,  Amy  Crain  of  the  Naval  Postgraduate 
School  Foundation  estimates  that  because  of  the  current 
system's  inability  to  foster  relationships  and  connections, 
the  Naval  Postgraduate  School  Foundation,  Incorporated  has 
missed  the  opportunity  to  raise  hundreds  of  thousands  of 
dollars  in  fundraising  and  donations,  donations  that  could 
be  used  for  things  such  as  supplementing  student  housing 
costs  or  assisting  in  guest  speaker  costs.  She  estimates 
that  with  a  competent  and  effective  system  in  place, 
fundraising  could  reach  nearly  seventy-five  percent  more 
potential  donors  than  are  currently  being  reached.  This 
increased  outreach  would  not  only  benefit  fundraising 
totals,  but  would  also  establish  a  connection  where  other 
information  could  be  shared. 
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B. 


RESEARCH  ISSUES 


From  these  areas  of  concern  it  is  evident  that  a  void 
still  exists  in  the  Naval  Postgraduate  School's  alumni 
system.  This  thesis  will  focus  on  filling  that  void  by 
detailing  requirements  for  a  Web-enabled  alumni  information 
system  that  will  allow  the  executive  staff,  faculty,  and 
alumni  of  the  Naval  Postgraduate  School  to  stay  connected 
even  after  they  have  departed  from  the  institution.  In 
order  to  create  such  a  system,  however,  several  problems 
must  be  addressed  and  resolved. 

•  How  to  design  an  effective  and  user-friendly 
system . 

•  Identify  who  the  main  stakeholders  of  the  system 
are,  and  how  they  will  interact  with  the  system. 

•  How  to  evaluate  the  costs  and  benefits  of 
outsourcing  such  a  system  compared  to  developing 
the  system  in-house. 

•  Determine  which  alternative  best  accomplishes  the 
goals  of  the  Naval  Postgraduate  School. 

•  How  to  design  a  system  that  allows  for  group 

modifications  to  be  accomplished  and  information 
to  be  shared  amongst  its  users. 

•  How  to  design  a  system  that  can  interact  with 

other  NPS  systems. 

•  How  to  design  a  security  structure  to  safeguard 
the  integrity  of  the  data. 

C .  METHODOLOGY 

To  gain  knowledge  on  how  alumni  information  was 

acquired  and  maintained  in  the  past,  several  research 

techniques  were  used.  Because  much  of  the  history 

surrounding  the  Naval  Postgraduate  School's  alumni  system 
is  not  well  documented,  a  significant  number  of  telephone 
and  personal  interviews  were  conducted  to  solicit 


3 


information  and  knowledge  about  past  and  future  systems. 
Interviews  were  conducted  ranging  across  the  spectrum  from 
representatives  of  potential  outsourcing  companies  to  key 
representatives  of  the  major  stakeholders  that  have  a 
specific  interest  in  the  development  of  the  system. 
Internet  resources,  books  written  that  were  relevant  to 
this  topic,  previous  theses,  and  other  relevant 
publications  were  also  used  to  gather  preparatory 
information . 

Research  was  done  to  design  a  system  that  allows  group 
modifications,  and  also  to  design  a  system  that  allows  for 
information  to  be  shared,  maintained,  and  accessed  by 
multiple  users. 

Determining  who  will  utilize  the  alumni  database,  how 
it  will  be  used,  and  the  responsibilities  of  those  using 
the  system  are  also  major  issues  surrounding  the 
implementation  of  a  new  system.  An  important  deliverable 
of  this  thesis  is  the  description  of  all  the  major 
participants  in  the  process  and  how  they  will  interact  with 
both  the  system,  and  one  another.  As  a  result  of 
stakeholder  interviews  and  research  of  past  usages  and 
requirements,  we  have  developed  use  cases,  which  are 
textural  narrative  descriptions,  for  each  of  the  main 
usages  for  this  system  and  have  documented  user 
responsibilities  in  ensuring  that  the  system  is  adequately 
maintained.  We  have  also  developed  actor/use  case  diagrams 
that  illustrate  the  interactions  between  the  users  and  the 
system  on  a  daily  or  weekly  basis.  Access  criteria  have 
also  been  produced  to  determine  who  requires  access  to  the 
system  and  what  types  of  access  they  will  be  granted. 
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The  ability  of  the  new  system  to  relate  and  interact 
with  other  systems  is  another  concern  that  has  been 
addressed.  Because  of  the  diversity  of  the  Naval 
Postgraduate  School's  systems,  led  by  the  PYTHON  Student 
Management  System,  measures  need  to  be  taken  to  ensure  that 
any  alumni  system  that  is  designed  needs  not  only  to 
interact  with  the  important  existing  systems,  but  should 
also  be  able  to  replace  many  of  the  ad  hoc  and  legacy 
systems  that  are  being  used  to  extract  and  utilize  alumni 
information  campus-wide.  This  can  only  be  done  if  a 
concise,  user-friendly  system  is  created.  A  study  was 
conducted  to  determine  the  levels  of  compatibility  that  the 
alumni  system  must  have  to  coexist  with  other  NPS  systems, 
and  how  its  development  may  result  in  other  departments 
discontinuing  the  usage  of  their  ad  hoc  alumni  systems. 

Also,  a  survey  was  conducted  to  determine  if  there  was 
any  interest  in  having  a  new  system  introduced.  A  cost- 
benefit  analysis  was  also  conducted  to  determine  if  the 
costs  of  creating  a  new  system  was  feasible  for  the  school. 
In  the  study,  the  benefits  and  costs  of  maintaining  and 
managing  the  system  in-house  are  compared  to  outsourcing 
that  responsibility  to  an  outside  agency. 

When  designing  an  interactive  database  that  primarily 
contains  information  about  military  personnel,  the  need  for 
security  is  patently  obvious.  Research  was  done  to  both 
identify  the  inherent  risk  associated  with  this  project, 
and  to  identify  the  risks  that  are  a  part  of  all 
interactive  Internet  projects.  This  thesis  offers  possible 
solutions  to  address  and  mitigate  the  risks  that  are 
associated  with  this  subject. 
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D.  STRUCTURE  OF  THE  THESIS 

Following  the  conclusion  of  this  chapter,  the  thesis 
will  flow  in  the  following  sequence.  Chapter  II  will 
chronicle  the  history  of  past  attempts  made  at  building  an 
adequate  system.  A  snapshot  will  be  provided  that  details 
past  submissions  and  their  shortfalls.  Chapter  III  will 
focus  on  whether  the  need  even  exists  for  an  alumni  system. 
Survey  results  will  be  provided  to  illustrate  that 
potential  users  feel  that  there  is  a  need  for  the  system  at 
the  school.  Also,  cost-benefit  analysis  results  will  be 
provided  to  show  the  potential  advantages  and  disadvantages 
of  the  system,  and  the  options  currently  being  explored  to 
get  the  usability  of  the  system  back  to  an  acceptable 
level.  Chapter  IV  will  take  a  look  at  how  the  actual 
system  should  look  and  be  set  up.  Information  will  be 
provided  detailing  how  the  system  will  interface  with  the 
current  systems  at  the  Naval  Postgraduate  School, 
specifically  the  PYTHON  Student  Management  System.  Use 

cases  will  be  provided  to  establish  a  guideline  for  how 
users  will  interact  with  the  system,  and  how  the  system 
will  respond  to  those  actions.  Also,  access  criteria  will 
be  provided  along  with  a  list  of  user  responsibilities  to 
show  the  different  access  levels,  what  that  level  will 
entail,  who  should  be  granted  that  level,  and  their 

responsibilities  to  the  system.  Questions  concerning 

security  will  be  presented  with  possible  solutions  to 
mitigate  concerns.  In  chapter  V,  we  summarize  the  work 
accomplished,  provide  a  list  of  system  requirements,  and 

conclude  with  other  system  recommendations. 

Over  the  past  fifteen  years  a  significant  amount  of 
progress  has  been  made  in  constructing  a  flexible  and 
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effective  alumni  system,  however  to  date,  no  system  has 
been  designed  that  ensures  that  alumni  information  is 
centrally  located,  easily  accessed,  easily  modified,  and 
easily  managed.  This  thesis  will  attempt  to  bring  the 
Naval  Postgraduate  School  closer  to  that  goal . 


7 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


II.  HISTORY  OF  THE  ALUMNI  DATABASE  SYSTEM 


For  many  years  the  Naval  Postgraduate  School  has 
struggled  to  find  ways  to  locate  and  remain  connected  with 
those  who  have  attended  and  graduated  from  the  school.  In 
an  effort  to  provide  a  point  of  reference  for  how  the  Naval 
Postgraduate  School's  Alumni  System  has  evolved  over  the 
last  couple  of  decades,  a  brief  snapshot  of  its  history  is 
provided  in  Figure  1.  Although  many  of  the  details  of 
previous  systems  will  be  excluded,  some  of  the  problems 
encountered  by  those  systems  will  be  shown  to  provide 
further  evidence  of  why  an  updated  or  new  system  is  needed. 


2000 

ALUMNI  DATABASE  TIMELINE  International  Assoc. 

Website  goes  Public 


1980  2002 


Figure  1.  Alumni  Database  Timeline 


The  Naval  Postgraduate  School's  first  known  foray  into 
the  alumni  relations  arena  came  in  the  early  1980s,  which 
is  when  the  school  instituted  its  first  alumni  management 
system  with  the  intent  of  staying  in  contact  with  the 
school's  graduates.  The  manual  system  that  was  designed 
and  implemented  during  that  time  turned  out  to  be  very 
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tedious,  inefficient,  and  difficult  to  manage.  The 
majority  of  past  and  present  student  records  that  were 
maintained  were  kept  alphabetically  in  filing  cabinets 
located  in  the  Office  of  the  Registrar.  When  it  was 
determined  that  a  record  required  modification  or 
cancellation,  attempts  were  made  by  the  Registrar's  Office 
to  make  the  necessary  changes,  however  because  the  records 
had  to  first  be  located,  and  then  manually  updated,  often 
times  the  changes  never  occurred.  Several  factors 
contributed  to  this  inefficiency,  but  most  frequently  this 
lack  of  progress  resulted  from  an  inadequate  amount  of 
personnel,  and  the  sheer  volume  of  the  records  that  had  to 
be  searched  to  locate  those  requiring  adjustments.  This 
resulted  in  thousands  of  records  that  were  either  outdated 
or  invalid. 

In  1986,  the  school  made  a  second  effort  to  address 
the  alumni  situation.  It  decided  that  maintaining  the 
records  of  all  the  graduates  electronically  rather  than 


manually 

would  better  prepare 

the 

institution 

for 

the 

future . 

During 

the  fall  of 

1986, 

the  Office 

of 

the 

Registrar 

started 

keeping  electronic 

records  of 

all 

the 

Naval  Postgraduate  School  graduates.  Although  the  burden 
of  having  enough  physical  space  to  house  all  the  records 
had  been  lifted,  several  challenges  still  existed.  One 
problem  resulted  from  the  conversion  of  paper  records  to 
electronic  ones.  The  combination  of  incomplete  and 

inaccurate  material  contained  in  the  hard  copies  along  with 
user  input  error  resulted  in  the  database  being  heavily 
populated  with  erroneous  data,  which  is  still  evident  in 
the  current  system.  Also,  the  time  and  effort  it  took  to 
convert  the  records  played  a  key  role  in  delaying  the 
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system's  usability.  It  would  have  required  nearly  around- 
the-clock  input  by  several  clerks  to  convert  the 
approximately  forty  thousand  existing  records;  therefore 
many  records  are  still  only  available  in  hard  copy  format. 

By  the  end  of  the  1980' s  users  realized  that  they 
still  were  not  getting  what  they  wanted  or  needed  from  the 
system,  so  in  1992,  after  attempting  several  manual  and 
electronic  alternatives  to  contact  past  and  present 
graduates,  another  effort  was  made  to  automate  the  entire 
alumni  system.  The  project  turned  out  to  be  quite 
extensive  and  involved  several  organizations,  primarily  the 
NPS  Office  of  the  Registrar,  the  NPS  Alumni  Association, 
and  the  NPS  Foundation.  These  entities,  along  with  several 
others,  tried  to  create  an  NPS  alumni  database  that  would 
not  only  store  all  of  the  alumni  records,  but  also  allow 
for  the  completion  of  many  different  functions  ranging  from 
printing  simple  reports  to  running  basic  information 
queries.  In  late  1992,  the  official  NPS  Alumni  Database 
was  established  and  made  available  to  the  school's  alumni. 
The  system  had  been  designed  utilizing  a  Focus  program  and 
was  expected  to  be  more  effective  and  efficient  than 
previous  attempts.  In  addition  to  having  extensive 
storage  capabilities  and  the  ability  to  complete  basic 
functions,  the  database  was  intended  to  easily  accommodate 
both  record  modification  and  cancellation;  unfortunately 
this  was  never  accomplished.  Although  this  system  solved 
some  of  the  problems  that  previous  systems  did  not  address, 
the  system  still  did  not  allow  records  to  be  searched  using 
designated  fields.  Also,  records  could  still  only  be 
accessed  on  an  individual  basis.  Although  modifications  to 
individual  records  could  be  done,  they  were  difficult  to 


11 


accomplish,  and  the  ability  of  make  group  modifications  was 
still  not  available.  The  system  was  also  not  very  user 
friendly;  in  fact  the  Deputy  Associate  Provost  stated  that, 
if  a  user  did  not  have  significant  knowledge  about  Focus, 
he  believed  it  was  virtually  impossible  to  extract 
meaningful  data  out  of  the  system.  Although  this 

particular  attempt  proved  to  have  very  limited 
capabilities,  it  did  have  a  positive  impact  on  the 
development  of  later  systems.  This  failed  system  laid  the 
groundwork  necessary  for  future  attempts  at  designing  an 
effective  alumni  system. 

Following  the  lead  of  other  prestigious  graduate  level 
institutions,  NPS  leaders  recognized  an  increasing  need  to 
establish  alumni  connections,  so  in  1997  an  Alumni 
Relations  Office  was  established.  Because  the  existing 
system  at  that  time  did  not  allow  the  Naval  Postgraduate 
School  the  access  that  it  wanted  or  needed,  another  attempt 
was  made  in  1998  to  get  a  handle  on  the  alumni  problem  by 
creating  a  relational  database  that  utilized  Structured 
Query  Language  (SQL) .  This  database  was  intended  to 
incorporate  all  the  alumni-related  information  made 
available  from  several  sources  around  campus  and  to  store 
it  in  one  general  location.  To  populate  this  database 
system,  information  would  be  supplied  from  several  sources: 

•  The  Focus  database  that  had  been  used  in  the 
early  1990' s.  The  information  from  this  database 
would  be  used  to  supply  data  about  present 
students,  as  well  as  the  limited  number  of 
graduates  that  had  been  entered  into  the  system. 
Although  this  system  had  not  performed  well,  much 
of  its  information  had  proven  to  be  reliable; 
therefore  it  was  transferred  to  the  relational 
system. 


12 


Outsourcing.  Bernard  C.  Harris  Incorporated,  a 
computer  service  company,  had  been  hired  by  the 
school  to  conduct  a  poll  to  locate  past  graduates 
whose  manual  records  had  been  deemed  incomplete 
or  inaccurate.  Harris'  findings,  once  verified, 
also  served  as  a  source  of  information  for  this 
database.  Universal  Internet,  another  computer 
firm,  who  had  been  hired  by  the  NPS  Alumni 
Association  to  work  on  creating  an  alumni 
management  system,  also  had  pertinent  information 
that  needed  to  be  transferred  to  the  relational 
database . 

The  Alumni  Relations  Office.  The  ARO  had  been 
maintaining  information  on  current  students  and 
recent  graduates  by  maintaining  manual  checkout 
and  update  sheets,  and  was  also  supplying  the 
relational  database  with  information. 


With  this  wide  variety  of  information  being  supplied 
by  several  sources,  the  job  of  those  commissioned  to 
develop  the  relational  system  became  increasingly 
difficult.  Furthermore,  soon  after  the  project  began,  many 
of  the  NPS  leaders  who  had  initiated  the  process  were 
beginning  to  transfer  or  retire,  which  caused  a  lapse  in 
momentum  and  direction. 

Once  modifications  to  the  system  began  to  occur,  a 
bevy  of  new  expectations  began  to  surface.  One  of  the  most 
important  changes  that  developed  from  this  turnover  was  the 
evolving  definition  of  an  alumnus.  The  new  leaders  decided 
that  not  only  should  the  new  system  track  students 
obtaining  master  degrees,  but  it  should  also  incorporate 
those  students  who  were  attending  and  eventually  graduating 
from  one  of  the  many  short  programs  that  the  school 
offered.  In  addition  to  traditional  master's  degree 
students,  graduates  of  these  short  programs  were  now  going 
to  be  considered  school  alumni  as  well.  This  new 
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definition  and  requirement  deterred  many  faculty  members 
and  caused  the  scope  of  the  project  to  increase  to  the 
extent  that  most  involved  believed  that  a  valid  system 
could  not  be  created  or  accurately  maintained. 

In  March  2000,  the  NPS  Alumni  Association,  in 
conjunction  with  Universal  Internet,  launched  the 
International  Alumni  Association  website,  which  provided 
access  to  the  alumni  database.  This  relational  database 
was  much  like  its  Focus  predecessor,  and  it  addressed  many 
of  the  problems  that  had  existed,  however  there  were  still 
other  issues  not  being  adequately  addressed.  One  issue  of 
great  importance  was  that  the  relational  database  did  not 
have  robust  search  capabilities.  According  to  Alumni 
Relations  Office,  this  system  was  also  not  very  user 
friendly.  This  was  primarily  because  the  system  was  being 
geared  toward  fundraising.  Although  the  school's  alumni 
were  the  main  focus  in  this  system,  many  others,  such  as 
retired  military  and  interested  civilians,  were  also 
included  in  the  database.  This  frequently  caused  confusion 
and  problems  for  the  system's  users.  Also,  without  having 
prior  knowledge  of  relational  systems  or  how  to  structure 
search  criteria,  users  found  it  difficult  to  retrieve 
desired  information. 

Another  problem  that  surfaced  involved  the  various 
sources  of  information  that  were  being  utilized.  Because 
the  information  that  the  system  was  intended  to  use  came 
from  several  places,  problems  arose  around  the  lack  of 
standardization  in  the  way  records  were  being  maintained. 
Because  some  records  were  stored  utilizing  student  names, 
and  others  were  stored  utilizing  file  numbers  or  social 
security  numbers,  the  system  and  its  users  were 
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understandably  confused.  There  were  no  standardized  fields 
common  across  the  various  sources  and  this  resulted  in 
corruption  of  the  system  and  its  ability  to  provide 
meaningful  and  truthful  data. 

Later  in  2000,  the  Alumni  Relations  Office  began 
conducting  studies  looking  at  ways  to  create  a  more 
efficient  and  effective  alumni  system.  During  this  process 
it  was  realized  that  while  the  SQL  system  had  served  as  a 
significant  stepping-stone  in  the  overall  alumni  process, 
something  else  was  needed  to  take  alumni  relations  to  the 
next  level  in  accessibility,  maintainability,  and 
manageability . 
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Ill . 


ANALYSIS  OF  FINDINGS 


In  the  early  stages  of  its  development  in  the  1980's, 
the  Naval  Postgraduate  School's  Alumni  System  was  faced 
with  several  challenges.  Because  those  in  charge  of  making 
crucial  decisions  in  determining  its  implementation  were 
skeptical,  supporters  of  the  system  were  required  to 
document  reasons  why  they  felt  it  was  necessary,  and  the 
added  value  that  it  would  provide  to  the  institution.  In 
2000  that  entire  process  seemed  to  go  full  circle  as  Naval 
Postgraduate  School  leaders  again  asked  those  committed  to 
an  alumni  system  to  justify  the  need  for  having  a  new  or 
updated  one,  and  again  supporters  began  preparing 
explanations  of  why  the  system  was,  in  their  eyes, 
important  and  necessary.  NPS  officials  were  asking  the 
tough  questions  because,  prior  to  obligating  more  money  to 
an  ineffective  system,  they  were  trying  to  ensure  that  an 
updated  or  new  system  was  really  beneficial  to  the  school. 
They  wanted  to  understand  the  value  that  the  system  might 
generate,  and  to  determine  how  much  the  system  would  cost. 
Over  the  course  of  the  past  year,  we  conducted  interviews 
and  mailed  out  surveys  that  address  these  specific 
questions . 

A.  SURVEY:  PURPOSE 

A  survey  was  mailed  out  to  individuals  at  the  Naval 
Postgraduate  School  that  either  had  experience  in  using 
past  alumni  systems,  or  a  significant  interest  in  the 
creation  of  a  more  effective  system.  The  fifteen 
individuals  selected  to  participate  in  this  survey  are 
listed  in  Figure  2.  These  individuals  were  identified  by 
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members  of  the  Alumni  Relations  Office  to  be  key 
representatives  of  the  major  stakeholders  in  the  Naval 
Postgraduate  School  Alumni  System. 


NAME 

TITLE/DEPARTMENT 

Christopher  Arias 

Student  Services  Officer,  SSO 

Tracy  Hammond 

Deputy  Associate  Provost,  Registrar 

Amy  Crain 

Director  of  Operations,  NPS  Foundation 

Danielle  Kuska 

Director  of  Research  Administration 

Rudy  Panholzer 

Dean,  GS  of  Eng.  &  Computation 

Jeff  Knorr 

Professor  &  Chairman,  Eng.&  Computation 

Bill  Hatch 

Acad.  Assoc.,  GS  of  Bus . &  Public  Policy 

Jeff  Kline 

Associate  Dean,  GS  of  Info.  Science 

Charles  Calvano 

Professor,  GS  of  Mechanical  Engineering 

Rob  Bourke  Jr. 

Alumni  Relations  Officer 

Sue  Higgins 

Military  Faculty,  Space  Systems 

Douglas  Brook 

Dean,  GS  of  Bus.  &  Public  Policy 

Gary  Roser 

Director  of  International  Programs 

Bob  Osterhoudt 

President,  Alumni  Association 

Julie  Filizetti 

Exec.  Director  of  Institutional 

Advancement  &  Communications 

Figure  2  . 


Survey  List 
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The  key  representatives  were  asked  several  questions 
on  the  importance  of  an  alumni  system.  Responses  were 
ranked  on  a  scale  from  1  (least  important)  to  5  (most 
important)  in  order  of  importance,  and  are  listed  in  Figure 

3. 


Do  you  feel  an  alumni  system  is  needed  at  the  Naval 
Postgraduate  School? 

Definitely  Needed  60% 

Greatly  Needed  20% 

Somewhat  needed,  but  not  required  20% 

How  much  will  an  alumni  system  be  used  by  you  and/or  your 
department  ? 

Daily  20% 

Weekly  40% 

Sparingly  (few  times  a  month)  40% 

Would  an  alumni  system  impact  your  job  and 
responsibilities? 

Significantly  20% 

Somewhat  70% 

Not  much  10% 

Quantify  the  potential  usages  for  the  system? 

Limitless  20% 

Very  few  limitations  60% 

May  have  some  limits,  but  not  significant  20% 

Would  you  promote  using  the  system? 

Yes,  would  require  it  60% 

Yes,  would  strongly  suggest  it  40% 


Figure  3. 


Survey  Results 
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A  list  of  important  intangible  features  for  an  alumni 
system  was  generated  from  interviews  that  were  conducted 
and  research  that  was  done.  Individuals  surveyed  and 
interviewed  were  also  asked  to  rank,  on  a  scale  from  1  to 
10,  the  importance  of  having  these  intangibles  in  a 
potential  alumni  system.  The  results  are  listed  in  Table 
1 . 


FACTOR 

Jeff 

Kline 

Amy 

Crain 

Bill 

Hatch 

Danielle 

Kuska 

Rudy 

Panholzer 

Jeff 

Knorr 

Tracy 

Hammond 

Julie 

Filizetti 

Charles 

Calvano 

AVERAGE 

Accuracy 

10 

10 

10 

10 

10 

10 

5 

10 

9 

9.3 

Reliability 

8 

10 

10 

10 

10 

10 

5 

10 

7 

8.9 

Ease  of  Use 

9 

10 

8 

6 

8 

8 

5 

8 

8 

7.8 

Affordability 

5 

8 

5 

6 

6 

10 

5 

9 

* 

6.8 

Interoperability 

7 

* 

8 

8 

5 

5 

3 

8 

* 

6.3 

Scalability 

5 

* 

5 

7 

4 

8 

5 

7 

* 

5.9 

Paperwork 

Reduction 

6 

5 

5 

5 

5 

8 

1 

8 

* 

5.4 

AVERAGE 

7.1 

8.6 

7.3 

7.4 

6.9 

8.4 

4.1 

8.6 

8.0 

*no  value 
recorded 

Table  1.  Critical  Success  Factors 

Although  the  survey  is  not  a  statistically  designed 
instrument,  it  does  provide  preliminary  indications  that  an 
alumni  system  is  needed.  Many  of  the  respondents  to  the 
survey  and  those  interviewed  indicated  that  they  believe 
that  not  only  is  an  alumni  system  needed,  but  it  is 
mandatory  if  the  school  wants  to  continue  to  be  a 
competitive  graduate  institution.  Also,  many  of  the 
participants  in  the  process  indicated  that  such  a  system 
could  have  a  noticeable  effect  on  how  they  performed  their 
job  and  the  level  at  which  it  was  performed.  Although  the 
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majority  of  those  surveyed  said  that  they  would  sparingly 
utilize  the  system,  it  is  easy  to  infer  that  others  with 
different  responsibilities  and  interest  may  have  an 
increased  need  to  use  the  system.  Most  also  felt  that  the 
system  was  nearly  limitless  in  ways  in  which  it  could  be 
used  and  the  effect  that  it  would  have  on  the  school.  Some 
feel  that  past  alumni  systems  have  failed  because  of  a  lack 
of  interest  and  because  of  how  old  systems  were  promoted. 
According  to  the  survey  results,  if  an  effective  product  is 
developed,  promotion  or  the  lack  thereof  would  be  a  non¬ 
issue.  Many  of  the  participants  indicated  that  they  would 
not  only  promote  the  usage  of  the  system,  but  would  require 
it . 

Although  the  survey  results  provided  indications  of 
the  potential  an  effective  system  might  have,  the  results 
were  not  conclusive.  This  suggests  that  further 
requirements  analysis  as  is  warranted.  Accordingly,  the 
next  step  we  undertake  is  a  cost-benefit  analysis.  An 
economic  analysis  is  a  systematic  approach  to  evaluating 
alternative  projects.  Underlying  such  an  analysis  is  the 
base  assumption  that  each  alternative  may  be  able  to  solve 
an  existing  problem  and  should  produce  certain  results 
while  requiring  and  utilizing  certain  resources.  In  this 
particular  situation,  there  are  several  options  being 
considered  to  solve  the  problem.  An  economic  analysis  was 
performed  on  each  of  these  options  to  determine  the 
comparative  costs  and  benefits,  and  to  determine  which 
alternative  is  the  most  appealing  from  this  perspective. 

B.  COST-BENEFIT:  PURPOSE 
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There  are  several  options  being  considered  for  the 
alumni  database  system  at  the  Naval  Postgraduate  School. 
They  include: 

•  Updating  and  utilizing  the  existing  SQL 

relational  database 

•  Outsourcing  the  creation,  population,  hosting, 
and  management  of  the  system  to  one  of  the 
following  vendors: 

•  Bernard  C.  Harris  Publishing  Inc. 

•  Sungard  BSR 

•  JSI  Fundraising  Inc. 

The  Naval  Postgraduate  School  Alumni  Database,  a  SQL 
relational  database,  is  the  system  currently  installed  at 
the  Naval  Postgraduate  School  for  alumni  relations.  The 
problems  with  this  system  are  extensive  and  have  been 
detailed  in  previous  chapters.  In  short,  the  system 
contains  several  shortfalls,  primarily  with  its  usability 
and  adaptability.  It  has  also  become  outdated  and  will  not 
allow  important  processes  to  be  successfully  completed  that 
are  necessary  in  today's  alumni  environment.  One  option 
being  considered  to  address  the  alumni  system  problem  is 
updating  the  SQL  system  that  currently  resides  at  the 

school.  There  are  several  advantages  and  disadvantages  to 
this  option  and  these  will  be  discussed  later. 

Outsourcing  the  management  of  the  alumni  database  to 
an  organization  outside  of  the  Naval  Postgraduate  School  is 
another  distinct  possibility  being  considered.  At  the 
outset  of  this  thesis,  there  were  several  corporations  that 
were  being  considered  for  the  job,  since  then  however,  the 
possible  contractors  have  been  whittled  to  the  three 
corporations  listed  above.  These  three  companies  have 
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provided  information  that  indicates  that  they  may  have  the 
ability  to  furnish  NPS  with  an  adequate  alumni  system. 


C.  DISCUSSION 

All  options  were  analyzed  by  utilizing  the  following 
methodology : 

•  An  assessment  of  the  advantages  and  disadvantages 
of  each  option. 

•  A  cost  breakdown  of  each  option  and  comparison 
across  options. 

•  An  evaluation  of  the  intangible  factors  as  they 
apply  to  the  options. 

•  A  calculation  of  the  Net  Present  Value  (NPV)  for 
each  option. 

The  following  data  were  used  to  calculate  NPV  for  all 
options : 

•  Discount  Rate:  10%  (when  evaluating  investment 

projects  that  will  continue  for  more  than  three 
years  in  a  government  organization,  discounting 
should  be  used  if  at  all  possible.  The 

prescribed  Department  of  Defense  discount  rate 
for  evaluating  alternatives  is  10%)  . 

•  Initial  Costs:  paid  upfront  at  "Time  Zero" 

•  Recurring  Costs:  paid  at  the  beginning  of  the 

year,  starting  in  year  1 

•  Life  Cycle:  5  years 

•  Scrap  Value:  zero  for  any  hardware  used 


1 .  Option  1 :  Updating  the  Existing  SQL  Relational 
Database 

This  option  involves  updating  the  SQL  relational 

database  that  currently  exists.  The  chief  advantage  in 
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this  option  appears  to  be  the  costs  associated  with 
revamping  the  currently  ineffective  system.  Familiarity  is 
another  advantage  of  this  option.  Because  the  system  has 
evolved  into  its  present  state,  those  who  have  been  around 
and  understand  how  to  use  it  are  comfortable  and  should  be 
benefited  by  utilizing  a  system  they  know.  However,  the 
advantages  of  this  option  could  very  easily  become 
disadvantages  if  the  work  required  to  make  the  system  an 
adequate  one  is  more  labor  intensive  than  currently 
expected  by  those  familiar  with  the  system.  The 
possibility  of  having  NPS  graduate  students  take  on  the 
project  was  considered,  however  it  was  determined  by  a 
panel  headed  by  members  of  the  Alumni  Relations  Office  that 
this  option  required  a  significant  amount  of  time  to 
organize  and  implement,  which  made  the  option  not  feasible. 

The  disadvantages  of  selecting  this  option  are 
considerable.  The  primary  disadvantage  of  updating  the  SQL 
system  is  that  the  expertise  needed  to  create  and  maintain 
such  a  system  in-house  currently  does  not  exist  and  is 
unavailable  here  at  the  school.  Although  updating  the 
system  would  address  some  of  the  current  system's  problems, 
several  others  will  continue  to  remain  unless  a  significant 
amount  of  money  is  spent  to  make  the  system  error-free. 

The  approach  used  to  assess  this  option  uses  estimated 
costs  of  maintaining  and  updating  the  SQL  system,  manpower 
operating  costs,  and  the  processing  of  all  paperwork 
associated  with  the  system.  The  cost  analysis  for  this 
option  is  displayed  in  Tables  2-4.  There  is  a  hint  of 
subjectivity  on  all  assessments,  however,  all  assessments 
made  are  based  on  individual  interviews,  interviews  of 
potential  outsourcing  companies,  and  research. 


Factor 


Assessment 


Average _ Computed  Value 


Accuracy 

4 

9.3 

37.2 

Reliability 

5 

8.9 

44.5 

Paperwork  Reduction 

3 

5.4 

16.2 

Interoperability 

6 

6.3 

37.8 

Ease  of  Use 

3 

7.8 

23.4 

Affordability 

9 

6.8 

61.2 

Scalability 

6 

5.9 

35.4 

TOTAL 


255.7 


Table  3 


Total  Cost  for  Option  1 


NET  PRESENT  VALUE 

FIXED  COSTS 

$  10000 

INITIAL  COSTS  (Paid  this 

year) $  5000 

RECURRING  COSTS 

Operating  Costs 

$  37000 

Time 

Absolute 

Discounted 

0 

$  47000 

$  47000 

1 

$  47000 

$  42723 

2 

$  47000 

$  38822 

3 

$  47000 

$  35297 

4 

$  47000 

$  32101 

5 

$  47000 

$  29187 

NET  PRESENT  VALUE 

$  255130 

Table  4.  Net  Present  Value  for  Option  1 

2.  Option  2:  Outsourcing;  Bernard  C.  Harris 

Publishing  Inc. 

This  option  has  the  potential  to  be  very  beneficial  to 
the  Naval  Postgraduate  School  because  Bernard  C.  Harris 
Inc.  is  very  experienced  in  providing  services  to  many  of 
the  nation's  premiere  educational  institutions.  Harris' 
expertise  in  this  field  is  not  easily  matched,  and 
selecting  this  option  could  garner  a  significant  "bang  for 
the  buck".  In  its  proposal,  Harris  vows  to  create  a  new 
system  for  the  Naval  Postgraduate  School  that  will  account 
for  all  of  the  requirements  and  risks  associated  with  the 
project,  and  they  will  do  so  at  a  relatively  inexpensive 
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price.  In  addition  to  offering  a  catered  system,  Harris 
has  also  indicated  that  they  will  assign  technicians  who 
will  be  solely  dedicated  to  the  Naval  Postgraduate  School's 
new  system.  Another  advantage  is  that  Harris  has  committed 
to  doing  what  it  terms  as  a  "search  and  locate"  for  all 
past  alumni  whose  records  presently  do  not  exist.  This 
service  is  included  in  Harris'  price  quote. 

Many  of  the  disadvantages  of  outsourcing  the  project 
to  Harris  is  similar  to  the  disadvantages  of  other 
outsourcing  projects;  loss  of  control  to  the  vendor, 
reduction  of  in-house  competency  due  to  vendor  dependency, 
and  lack  of  security.  A  major  inherent  risk  in  outsourcing 
a  project  that  involves  military  officer  information  is 
security.  Harris  proposes  that  it  will  alleviate  all  NPS 
security  concerns,  and  adhere  to  DOD  security  criteria. 

The  approach  used  to  assess  this  option,  in  most 
instances,  uses  prices  furnished  by  the  company  and 
commercial  industry  prices  for  hardware.  Estimates  are 
used  to  account  for  manpower  costs  when  applicable.  Fees 
submitted  by  Harris  did  not  project  past  current  year, 
therefore  future  year  costs  are  estimates.  The  cost 

analysis  for  this  option  is  displayed  in  Tables  5-7. 
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Factor 

Assessment 

Average 

Computed  Value 

Accuracy 

9 

9.3 

83.7 

Reliability 

8 

8.9 

71.2 

Paperwork  Reduction 

7 

5.4 

37.8 

Interoperability 

7 

6.3 

44.1 

Ease  of  Use 

8 

7.8 

62.4 

Affordability 

9 

6.8 

61.2 

Scalability 

8 

5.9 

47.2 

TOTAL 

7.2 

407.6 

Table  5.  Intangible  Factors  for  Option  2 

TOTAL  COST 

FIXED 

ITEM  UNITS  PER  UNIT  TOTAL 

Data  Entry  Fee  $  5600 

Email  Address  Append  $  1700 

Search  and  Locate  Service  $  7700 

$  15000 

RECURRING 

ITEM  UNITS  PER  UNIT  TOTAL 

Maintenance,  software,  $  22400 

hardware 

TOTAL  COSTS  $  37400 

Table  6. 


Total  Cost  for  Option  2 


FIXED  COSTS 

NET  PRESENT  VALUE 

$  15000 

INITIAL  COSTS  (Paid  this 

year)  $  22400  ($11200  at 

contract,  $11200  at  delivery) 

RECURRING  COSTS 

Operating  Costs 

$  22400 

Time 

Absolute 

Discounted 

0 

$  22400 

$  22400 

1 

$  37400 

$  33997 

2 

$  37400 

$  30892 

3 

$  37400 

$  28087 

4 

$  37400 

$  25544 

5 

$  37400 

$  15863 

NET  PRESENT  VALUE 

$  156783 

Table  7.  Net  Present  Value  for  Option  2 

3.  Option  3:  Outsourcing;  Sungard  BSR 

This  is  a  second  option  in  outsourcing  the  system  to 
an  outside  organization.  A  major  advantage  of  the  Sungard 
software  is  its  robustness.  Sungard' s  latest  release  in 
the  market  is  the  8.2  version  of  its  Smartcall  system. 
Sungard  has  forecasted  version  9.0  being  released  within 
the  next  year.  Serving  over  twenty-thousand  clients 

worldwide  and  forty-seven  of  the  world' s  top  fifty  largest 
financial  institutions,  Sungard  has  definitely  established 
itself  in  the  unique  systems  market,  which  provides  solid 
evidence  that  the  company  is  up  to  the  challenge  of 
handling  the  requirements  of  the  Naval  Postgraduate  School. 
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Sungard' s  Advanced  System  is  a  Windows  based  system  that 


can  utilize  either  a  UNIX,  Windows  NT,  or  Windows  2000 
server  running  MS  SQL  Server,  or  Oracle  8.0.6  or  higher. 

A  major  disadvantage  of  Sungard  option  lies  in  the 
cost  associated  with  purchasing  the  system.  Although 
Sungard  would  be  able  to  accommodate  the  NPS  requirements, 
things  such  as  an  online  directory,  additional  technical 
support,  and  alumni  website  construction  would  require 
additional  funding.  These  costs,  in  addition  to  other 
inherent  outsourcing  issues,  cause  this  option  to  compare 
unfavorably  with  other  options. 

The  approach  used  to  assess  this  option  also  uses 
prices  furnished  by  the  company  and  commercial  industry 
prices  for  hardware.  The  cost  analysis  for  this  option  is 
displayed  in  Tables  8-10. 


Factor 

Assessment 

Average 

Computed  Value 

Accuracy 

10 

9.3 

93 

Reliability 

9 

8.9 

80.1 

Paperwork  Reduction 

10 

5.4 

54 

Interoperability 

8 

6.3 

50.4 

Ease  of  Use 

10 

7.8 

78 

Affordability 

4 

6.8 

27.2 

Scalability 

9 

5.9 

53.1 

TOTAL 

7.2 

435.8 

Table  8 . 

Intangible  Factors 

for  Option  3 
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TOTAL  COST 

FIXED 

ITEM 

UNITS 

PER 

UNIT 

TOTAL 

Advance 

$  54800 

Licensing 

$  12000 
$  66800 

RECURRING 

ITEM 

UNITS 

PER 

UNIT 

TOTAL 

Maintenance 

$  23300 

Internet  Interface 

$  9900 

$  33200 

TOTAL  COSTS 

$  100000 

Table  9. 

Total  Cost 

for 

Option 

3 

NET  PRESENT 

VALUE 

FIXED  COSTS 

$  66800 

INITIAL  COSTS  (Paid  this 

;  year) $  54800 

RECURRING  COSTS 

Operating  Costs 

$  37000 

Time 

Absolute 

Discounted 

0 

$  54800 

$ 

54800 

1 

$  100000 

$ 

90900 

2 

$  100000 

$ 

82600 

3 

$  100000 

$ 

75100 

4 

$  100000 

$ 

68300 

5 

$  100000 

$ 

62100 

NET  PRESENT  VALUE 

$ 

433800 

Table  10. 

Net  Present  Value 

for  Option  3 

4.  Option  4:  Outsourcing;  JSI  Fundraising,  Inc. 

This  is  the  third  option  for  outsourcing  the 
maintenance  and  management  responsibility  of  the  Alumni 
System.  The  advantages  of  this  option  relate  to  JSI's 
track  record  in  the  fundraising  arena.  The  company  founded 
in  1978,  promotes  its  new  Millennium  fundraising  software 
as  the  solution  to  many  of  the  Naval  Postgraduate  School's 
alumni  problems.  The  sophisticated  and  versatile  software 
is  a  Windows  based  product  that  is  designed  for  educational 
institutions  much  like  NPS,  in  fact  several  reputable 
educational  and  medical  institutions  are  currently  using  it 
worldwide . 

The  disadvantages  of  this  option,  in  addition  to  those 
inherent  in  outsourcing,  are  that  JSI  specializes  in 
fundraising  and  that  is  only  a  fraction  of  what  an  NPS 
alumni  database  will  be  required  to  do.  Although  JSI 
asserts  that  their  system  and  staff  can  accommodate  the 
requirements,  their  level  of  expertise  in  other  areas 
required  by  the  NPS  system  is  questionable.  Another 
disadvantage  to  the  JSI  proposal  is  that  no  plan  was  given 
to  search  and  locate  information  about  those  alumni  who 
currently  do  not  exist  in  the  database.  If  an  effort  were 
made  to  capture  this  information,  it  would  have  to  be 
coordinated  with  another  organization.  Although  JSI  would 
provide  significant  advantages  in  fundraising,  at  first 
blush,  the  system  that  they  propose  does  not  seem  flexible 
enough  to  handle  all  of  the  Naval  Postgraduate  School's 
requirements.  Additionally,  fundraising  is  not  a  priority 
of  the  Naval  Postgraduate  School. 
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The  approach  used  to  assess  this  option  also  uses 
prices  furnished  by  the  company  and  commercial  industry 


prices  for  hardware.  The  cost  analysis  for  this  option  is 
displayed  in  Figures  11-13. 


Factor _ 

Accuracy 

Reliability _ 

Paperwork 

Reduction 

Interoperability 

Ease  of  Use 

Affordability 

Scalability 


Assessment 


Average 


Computed  Value 


TOTAL 


338.6 


Table  11. 


Intangible  Factors  for  Option  4 


FIXED 


TOTAL  COST 


ITEM 

Millennium 
User  license 
License  for  Oracle 


UNITS 


PER  UNIT 


TOTAL 
$  29000 
$  6750 

$  5000 

$  40750 


RECURRING 


ITEM  UNITS 

Browser  Interface  Module 
Maintenance 


PER  UNIT 


TOTAL 
$  10000 
$  8600 
$  18600 


TOTAL  COSTS 


$  59350 


♦Total  Cost  does  not  include  cost  for  "search  and  locate"  requirement 


Table  12 . 


Total  Cost  for  Option  4 


NET  PRESENT  VALUE 

FIXED  COSTS 

$  40750 

INITIAL  COSTS  (Paid  this 

year) $  40750 

RECURRING  COSTS 

Operating  Costs 

$  29000 

Time 

Absolute 

Discounted 

0 

$  29000 

$ 

29000 

1 

$  59350 

$ 

53949 

2 

$  59350 

$ 

49023 

3 

$  59350 

$ 

44571 

4 

$  59350 

$ 

40536 

5 

$  59350 

$ 

36856 

NET  PRESENT  VALUE 

$ 

253935 

Table  13.  Net  Present  Value  for  Option  4 

D .  SUMMARY 

Initial  Cost  Comparison.  The  initial  costs  of 

modifying  the  current  SQL  system  appears  to  be  easily  the 
most  inexpensive  of  the  options.  However,  because  the 
current  system  will  require  such  an  extensive  overhaul  to 
get  it  to  an  acceptable  level  and  to  make  it  technically 
competitive  with  other  options,  modifying  the  system  is  not 
a  logical  choice.  The  next  best  choice,  according  to  the 
initial  cost  statistics,  is  outsourcing  the  system  to 
Bernard  C.  Harris  Publishing  Inc. 

Total  Cost  Comparison.  Outsourcing  the  system 

requirement  to  Harris  is  the  best  choice  in  terms  of  the 
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total  cost  involved.  Totaling  $  37,400,  this  option's 
nearest  competitor  totaled  $9,600  more.  Not  only  does  this 
option  have  the  most  inexpensive  costs,  but  it  also  has  the 
lowest  net  present  value.  Again,  although  the  Sungard 
system  will  provide  many  advantages,  the  total  cost  for 
selecting  this  system  is  the  most  expensive  option 
considered . 

Comparison  of  the  Intangibles.  In  the  category  of 
intangibles,  the  system  offered  by  Sungard  proved  to  be  the 
highest  scorer.  With  a  total  rating  of  435.8,  it  is  easy 
to  understand  why  Sungard  seems  to  be  such  a  great  fit  for 
the  Naval  Postgraduate  School.  Modifying  the  current  SQL 
system  attained  the  lowest  score  of  any  of  the  options. 
Although  the  SQL  option  provided  lower  costs,  the  factors 
that  are  important  to  the  stockholders  probably  will  not  be 
accommodated  by  the  system.  In  the  intangibles,  Bernard  C. 
Harris,  Inc.  was  very  competitive  with  Sungard  as  it 
obtained  a  rating  of  407.6.  JSI  Inc.  finished  third  with  a 
rating  of  338.6.  A  chart  of  all  the  options  is  listed  in 
Table  14. 
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SUMMARY 

COMPARISON 

OPTION 

INTANGIBLE  VALUE/ 
AVERAGE  FACTOR 

TOTAL  COST 

NPV 

1 (Update  DB) 

255.7 

/ 

5.1 

$  47,000 

$ 

255, 130 

2 (Harris ) 

407 . 6 

/ 

00 

$  37,400 

$ 

156, 783 

3 (Sungard) 

435.8 

/ 

8 . 7 

$100, 000 

$ 

433,800 

4  (JSI) 

338 . 6 

/ 

6.7 

$  59,350 

$ 

253, 935 

Table  14.  Summary/Comparison  of  Options 

E .  RECOMMENDATIONS 

As  previously  noted,  there  are  several  important 
factors  that  have  an  affect  in  determining  which  option 
provides  the  best  fit  for  the  Naval  Postgraduate  School. 
Although  the  overall  cost  of  the  system  seems  slightly  more 
important  than  the  intangibles,  a  comparison  of  a 
combination  of  the  factors  will  decide  which  option  is  the 
most  advantageous. 

Although  JSI  Inc.  was  not  the  leader  in  any  of  the 
categories  presented,  its  expertise  in  fundraising  and  its 
experience  with  other  educational  institutions  make  it  a 
reasonable  option  in  the  decision  making  process.  However, 
JSI's  lack  of  experience  in  other  areas  where  an  alumni 
database  could  be  used,  and  its  inability  to  accommodate 
"search  and  locate"  procedures  on  approximately  20,000 
alumni  not  currently  present  in  the  Alumni  Database,  make 
this  option  less  desirable. 
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Modifying  the  current  SQL  system  is  the  most 
advantageous  option  with  regard  to  initial  costs  and  it  is 
very  competitive  in  total  costs.  However,  this  option  is 
severely  lacking  in  the  intangibles,  and  since  it  is  highly 
questionable  if  the  expertise  that  is  required  to  create 
and  maintain  the  system  is  available  at  NPS,  we  believe 
this  option  is  high  risk  and  therefore  inferior  to  other 
alternatives . 

Sungard  offers  a  great  product  with  a  proven  track 
record.  The  major  problem  with  the  system  is  its 
relatively  high  price.  Although  this  system  seems  to  be  a 
great  fit  for  the  Naval  Postgraduate  School  and  excels  in 
the  intangibles,  Sungard' s  total  cost  of  $100,000  and  its 
net  present  value  exceeding  $  400,000  significantly  reduces 
its  desirability. 

Outsourcing  the  installation,  population,  and 
management  of  the  Naval  Postgraduate  School's  Alumni  System 
to  Bernard  C.  Harris  Publishing,  Inc.  seems  to  be  the  most 
desirable  choice  according  to  the  established  evaluation 
criteria.  On  all  fronts,  this  option  is  either  the  leader 
or  is  very  competitive  with  the  other  options  in  every 
category.  Harris,  much  like  Sungard,  has  a  proven  product 
that  has  earned  a  solid  reputation.  With  the  lowest  total 
costs  and  net  present  value  of  any  of  the  options,  and  a 
very  high  score  in  the  intangibles,  we  recommend  that  the 
Naval  Postgraduate  School  pursue  this  option  as  its 
solution  to  an  alumni  system. 
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IV. 


SYSTEM  REQUIREMENTS 


A .  STAKEHOLDERS 

Now  that  we  have  determined  that  outsourcing  the 
creation  and  management  of  the  Alumni  System  in  the  near 
term  is  the  most  desirable  option,  we  have  system 
requirement  issues  that  must  be  addressed.  First,  we  must 
identify  the  key  stakeholders  in  the  system.  The  main 
stakeholders  who  have  a  vested  interest  in  the  design  and 
implementation  of  an  effective  and  efficient  alumni  system 
are  listed  in  Figure  4. 


MAJOR  STAKEHOLDERS 

Alumni  Relations  Office  (ARO) 

Alumni  Association 

Naval  Postgraduate  School  Alumni 

Office  of  the  Registrar 

Department  of  International  Programs 

Naval  Postgraduate  School  Departments 

Student  Services 

Naval  Postgraduate  School  Foundation 


Figure  4 . 


Major  Stakeholders 
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B .  USE  CASES 

Throughout  the  requirements  analysis  for  the  alumni 
system,  we  employ  use  cases,  which  are  narrative  documents 
that  describe  the  sequence  of  events  that  occur  when  a 
system  and  user  interact.  Succinctly,  use  cases  are 
stories  or  cases  of  how  a  system  is  used  by  its  customers. 
In  constructing  the  use  cases  input  was  obtained  from  many 
of  the  system's  potential  users,  as  well  as  its  potential 
creators  and  managers.  Many  of  the  use  cases  provided 
within  this  thesis  are  basic  function  use  cases,  which  show 
the  essence  of  the  alumni  process  and  its  fundamental 
motivation  without  providing  an  overwhelming  amount  of 
design  detail.  We  decided  that  use  cases  were  needed  to 
ensure  that  the  overall  process  was  well  understood  and 
could  be  reviewed  if  required.  A  series  of  expanded  use 
cases  is  provided  in  the  appendix  in  Tables  17-27. 


C .  DATABASE  SCHEMA 

Also  throughout  performing  the  requirement  analysis 
for  the  alumni  system,  a  database  schema  was  constructed. 
Although  the  schema  provided  should  not  be  viewed  as  a 
final  submission,  it  does  establish  a  framework  for  future 
databases.  Database  schemas  basically  define  the  structure 
of  a  database.  Schemas  combine  tables,  relationships, 
domains,  and  the  business  rules  that  will  be  used  in  the 
database's  functions,  and  they  serve  as  foundations  upon 
which  database  applications  are  built.  In  designing  the 
database  schema  for  the  alumni  system,  input  was  solicited 
from  potential  system  users  and  managers.  Those 

individuals  were  asked  questions  that  pertained  to  what 
type  of  alumni  information  was  most  important  to  them,  what 
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reports  were  expected  to  be  generated  by  the  system,  what 
queries  were  expected  to  be  performed,  and  what  they  would 
like  to  see  the  database  be  able  to  accomplish.  What 
resulted  was  the  schema  shown  in  Figures  5  and  7 .  The 
schema  presented  consists  of  twelve  tables  that  will  store 
all  of  the  required  data.  Data  requirements  are  listed  for 
each  of  the  tables,  as  are  the  relationships  that  connect 
them.  The  Alumni  Table,  located  within  the  schema,  will 
store  the  largest  amount  of  data,  as  it  will  serve  as  the 
focal  point  of  the  entire  system.  The  alumni  data  required 
ranges  from  social  security  number  to  military  branch  of 
service.  The  primary  key  in  this  table  will  be  AlumnilD. 
The  Alumni  Table  is  where  most  of  an  alumni's  personal  data 
will  be  stored,  and  is  the  table  that  will  probably  be  used 
most  frequently.  The  Address  Table  is  designed  to  store 
the  alumni's  current  address.  The  table  contains  AddressID 
as  its  primary  key.  This  table  has  a  one-to-many 
relationship  with  the  Alumni  Table  because  one  alumnus  can 
have  many  addresses.  The  Undergraduate  Table  is  designed 
to  store  all  of  the  alumni's  undergraduate  data.  This 
table  will  store  the  alumni's  undergraduate  university 
name,  the  type  of  degree  attained,  and  the  year  graduated. 
In  this  table  the  primary  key  is  UndergraduatelD .  This 
table  also  has  a  one-to-many  relationship  with  the  Alumni 
Table.  The  Donations  Table  is  established  to  monitor  the 
alumni's  donation  history.  The  primary  key  in  this  table 
is  DonationsID.  This  table  also  has  a  one-to-many 
relationship  with  the  Alumni  Table.  The  AlumnusDegreeType 
and  AlumnusCurric  Tables  are  join  tables  in  this  schema. 
Join  tables  are  established  to  act  as  conduits  that  allow 
data  to  be  more  easily  transmitted  between  tables. 
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Relationships  between  these  tables  and  the  Alumni  Table  are 
one-to-many.  The  DegreeType  Table  will  store  data  about 
the  degree  that  the  alumnus  attained  while  attending  the 
school.  DegreeTypelD  is  the  primary  key  in  this  table. 
This  table  has  a  one-to-many  relationship  with  the 
AlumnusDegreeType  join  table.  The  Curriculum  Table  is 
designed  to  store  the  alumni' s  curricula  information  when 
he  attended  the  school.  The  primary  key  in  this  table  is 
CurricID.  This  table  has  a  one-to-many  relationship  with 
the  AlumnusCurric  join  table.  The  Track  Table  is  designed 
to  store  data  on  the  alumni's  degree  track.  Some  NPS 
fields  of  study  can  contain  several  tracks  that  can  be 
pursued,  this  table  will  store  this  data  as  it  pertains  to 
an  alumnus.  The  primary  key  in  this  table  is  TrackID. 
This  table  has  a  many-to-one  relationship  with  the 
Curriculum  Table.  The  Status,  State,  and  Country  Tables  in 
the  schema  are  all  look-up  tables.  Look  up  tables  store 
and  provide  access  to  static  data  that  is  required  in  the 
database.  These  tables  will  be  used  to  acquire  the  status 
(active  duty,  reserve,  retired,  deceased)  of  an  alumnus, 
and  the  state  and  country  of  residence.  The  alumni 
database  schema  is  shown  if  Figure  5. 
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Database  Schema 


SECURITY  ISSUES 

The  issue  of  system  security  is  clearly  an  obstacle 
must  be  addressed  prior  to  implementation  of  any 
racting  decision.  In  this  project,  as  with  many  other 
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Internet  endeavors,  there  are  several  security  risks  that 
can  compromise  system  integrity. 

1 .  Authentication 

One  of  those  potential  hurdles  is  authentication. 
Because  of  the  nature  of  the  data  that  will  be  secured  in 
the  Alumni  System,  the  ability  to  authenticate  users  is  a 
vital  element  in  this  system.  There  are  several 
authentication  methods  that  are  available  for  this  type  of 
system  and  each  carries  comparative  advantages  and 
disadvantages.  In  evaluating  the  possible  solutions  for 
the  Alumni  System,  three  methods  will  be  studied  to 
determine  which  provides  the  best  fit:  Basic  Access 
Authentication,  Digest  Access  Authentication,  and  Secure 
Socket  Layer  Authentication. 

Basic  Access  Authentication  is  a  part  of  the  Hypertext 
Transport  Protocol  (HTTP)  .  In  this  scheme,  the  user  must 
authenticate  himself  with  a  user  ID  and  password  to  access 
each  realm  of  the  system.  Within  each  realm,  protected 
resources  are  partitioned  off  with  their  own  authentication 
databases.  When  a  request  is  made  for  a  document  that 
belongs  to  a  protected  space,  the  server  will  require  the 
user  to  authenticate  himself,  and  then  a  browser  will 
prompt  the  user  for  an  ID  and  password.  If  this 
information  is  validated,  the  user  will  be  allowed  to 
access  the  data  that  he  is  requesting.  Once  authenticated, 
the  browser  remembers  the  ID  and  password,  so  that  when 
another  data  request  is  made,  the  user  will  not  have  to  be 
prompted  again.  The  user  IDs  and  passwords  utilizing  this 
scheme  are  stored  in  an  encrypted  form. 
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The  advantages  to  using  this  authentication  approach 
in  the  Alumni  System  primarily  involve  ease  of  use.  Users 
will  find  this  method  very  easy  to  use  because  it  is  what 
most  users  are  accustomed  to.  This  type  of  authentication 
is  installed  on  most  web  server  and  browser  software. 

A  disadvantage  to  utilizing  this  method  is  that  it  is 
difficult  to  manage.  If  the  Alumni  System  employed  this 
method,  each  server  being  used  would  have  to  issue  and 
securely  store  an  ID  and  password  for  each  user. 
Additionally,  usernames  and  passwords  would  have  to  be 
prearranged  manually  by  a  system  administrator,  which  could 
become  a  very  time  consuming  process.  Also,  because  the 
process  would  be  a  manual  one,  the  possibility  of  inputting 
erroneous  material  would  be  increased.  A  major 
disadvantage  of  this  scheme  is  that  IDs  and  passwords  would 
be  transmitted  over  the  network  in  the  clear.  This  would 
permit  eavesdroppers  to  relatively  easily  obtain  the 
information  necessary  to  breach  the  system.  Basic  Access 
Authentication  is  also  susceptible  to  DNS  and  IP  spoofing. 
Because  clients  have  no  way  of  authenticating  the  server, 
they  are  prone  to  security  attacks.  With  the  proper 
equipment,  anyone  with  a  strong  desire  to  access  the  system 
can  easily  do  so  when  this  scheme  is  employed. 

Combining  IP  addresses  and  domain  names  with  Basic 
Access  Authentication  offers  a  more  acceptable  approach. 
By  employing  these  techniques,  the  Naval  Postgraduate 
School  could  restrict  access  to  the  alumni  servers  by 
permitting  only  those  requests  that  come  from  within  its 
own  domain  to  enter.  This  approach,  however,  might  limit 
participation,  especially  since  many  of  the  proposed 
system's  users  would  be  located  around  the  world.  Using 
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the  IP  addresses  and  domain  names  in  concert  with  Basic 
Access  Authentication  would  make  it  more  difficult  to  spoof 
the  system,  however  the  ability  would  still  exist  to 

penetrate  the  system,  and  subsequently  there  would  be  no 
guarantee  that  the  person  contacting  the  server  is  who  he 
claims  to  be. 

These  shortcomings  render  this  authentication  method, 
if  used  alone,  inadequate  for  the  Alumni  System.  Although 
the  Basic  Access  Authentication  scheme  may  keep  away  the 
casual  surfer,  it  will  not  protect  against  those  really 
wanting  to  gain  access  to  the  system. 

Another  authentication  method  available  to  the  Naval 

Postgraduate  School  Alumni  System  is  Digest  Access 
Authentication.  This  scheme  is  much  like  Basic  Access 
Authentication,  but  it  avoids  the  glaring  weakness  of 
sending  passwords  in  the  clear.  This  scheme  also  uses  the 
challenge-response  method,  however,  nonces  are  used  to 
prevent  replay  attacks  by  possible  system  hackers.  A  nonce 
is  a  parameter  that  varies  with  time.  Frequently  used 
nonces  are  things  such  as  time  stamps  and  visit  or  usage 
counters  on  web  pages.  Because  nonces  change  with  time, 
they  are  used  to  limit  or  prevent  unauthorized  replay  or 

reproduction  of  a  file.  Nonces  make  it  easier  to  tell 
whether  an  attempt  at  replay  or  reproduction  is  legitimate. 
In  Basic  Access  Authentication  if  an  eavesdropper  obtains  a 
password,  he  normally  has  access  to  everything  that  is 

under  the  umbrella  of  that  password,  but  in  Digest  Access 
Authentication  an  eavesdropper  would  only  obtain  access  to 
that  particular  transaction,  not  the  password  or  other 
information  accessible  by  that  password.  In  short,  the 
eavesdropper  could  implement  a  replay  attack,  but  it  would 
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work  only  with  a  request  for  the  same  document,  and  even 
this  could  be  made  difficult  with  a  well-selected  nonce. 
Another  advantage  to  this  method  is  that  the  HTTP  server 
does  not  actually  need  to  know  the  user' s  clear  text 
password.  As  long  as  the  checksum  of  the  user  ID,  the 
realm,  and  the  password  is  available  to  the  server  the 
authorization  header  can  be  verified  and  validated. 

A  possible  drawback  to  this  would  occur  if  the 
password  files  are  compromised,  which  would  then  give  the 
hacker  immediate  access  to  all  documents  in  that  specific 
realm.  There  are  other  disadvantages  to  the  Digest  Access 
Authentication  scheme  as  well.  Like  Basic  Access 

Authentication,  the  user  name  and  password  in  Digest  Access 
Authentication  must  be  prearranged  in  some  fashion,  which 
again  may  be  very  time  consuming  and  error-prone.  Also 
Digest  Access  Authentication  is  susceptible  to  man-in-the- 
middle  attacks.  This  happens  because  there  is  no  way  for 
clients  to  authenticate  servers  in  this  scheme.  Man-in- 
the-middle  attacks  are  relatively  simple;  they  usually 
happen  when  an  attempt  is  made  to  coax  the  client  into 
giving  up  its  password.  An  example  of  this  might  occur 
after  the  server  has  received  the  client's  request  and  is 
issuing  a  challenge.  A  hacker,  or  middleman,  could 
intercept  that  challenge  and  issue  another  one.  Not 
knowing  this  spoof  has  occurred,  the  client  would  issue  a 
response  that  contains  the  user  name  and  password,  which  in 
turn,  would  give  the  hacker  access  to  the  system.  A  final 
disadvantage  to  this  scheme  is  that  it  cannot  be  used  for 
any  transaction  that  requires  encrypted  content,  which 
would  severely  limit  the  Alumni  System. 
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Although  Digest  Access  Authentication  addresses  some 
of  the  concerns  that  Basic  Access  Authentication  does  not, 
it  is  still  considered  a  weak  authentication  method. 
Digest  Access  Authentication  will  normally  keep  away  the 
casual  surfer  and  the  mediocre  hacker,  but  when  used  alone 
it  still  lacks  in  the  ability  to  protect  valuable 
information . 

A  third  authentication  method  is  the  popular  Secure 
Socket  Layer  (SSL) .  This  scheme  was  specifically  developed 
to  provide  privacy  and  data  integrity  by  using  encryption 
and  message  authentication  codes.  SSL  is  designed  to 
provide  security  for  protocols  like  HTTP,  FTP,  and  TELNET 
by  interposing  themselves  between  TCP  and  higher-level 
protocols.  SSL  allows  client/server  applications  to 
communicate  in  a  way  that  prevents  eavesdropping, 
tampering,  or  forgery.  One  way  that  this  scheme  is  used  is 
when  an  application  is  summoned  by  the  SSL  to  set  up  a 
channel.  During  the  SSL  handshake  protocol,  public  key 
cryptology  is  used  to  authenticate  the  communicating 
parties  and  exchange  session  keys.  An  example  of  how  this 
would  be  used  in  the  Alumni  System  would  occur  when  a  user 
prompts  the  client  to  send  the  server  a  message  requesting 
access.  The  server  would  send  a  certificate,  which  would 
include  the  server' s  public  key,  and  the  client  would 
create  a  session  key  and  send  it  encrypted  in  the  server' s 
public  key  so  that  only  the  server  could  access  it.  The 
remainder  of  the  transmission  would  be  encrypted  utilizing 
the  session  key.  Besides  protecting  against  spoofs, 
another  advantage  of  SSL  is  that  it  is  application 
independent.  This  means  that  higher-level  protocols  can 
layer  on  top  of  the  SSL  protocol  transparently.  Also,  SSL 
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is  very  adaptable,  which  is  important  to  the  Alumni  System. 
Because  it  is  easy  to  modify  or  add  support  to  SSL,  SSL  can 
easily  accommodate  a  significant  increase  in  the  number  of 
browsers.  Using  a  strong  authentication  method  such  as  SSL 
is  an  adequate  way  to  protect  the  information  being 
exchanged  in  the  Alumni  System.  This  scheme  would  be 
especially  useful  when  credit  card  donations  and  other 
highly  secure  and  confidential  transactions  are  being 
transmitted  in  the  system. 

Increased  security  in  the  Alumni  System  can  be 
realized  by  combining  two  or  more  of  these  three  schemes. 
In  choosing  an  authentication  method  that  best  serves  the 
requirements  of  the  Alumni  System,  not  only  authentication 
of  the  user  and  server,  but  also  the  integrity  of  the 
message  and  the  degree  of  confidentiality  should  be 
considered.  Obviously  there  is  no  single  best  scheme  that 
will  totally  protect  the  system  from  all  hackers,  however 
our  recommendation  for  providing  an  acceptable  level  of 
security  is  to  utilize  the  SSL  scheme  to  protect  users  who 
are  transmitting  secret  material  in  the  system,  augmented 
by  a  form  of  Digest  Access  Authentication  to  assist  in  that 
protection.  We  believe  this  combination  will  give  the 
Alumni  System  a  secure  platform  to  exchange  information  and 
ideas  over  the  Internet. 

2.  Passwords,  Backups,  and  Packet  Filtering 

Other  security  issues  that  may  cause  concern  in  the 
Alumni  System  are  weak  passwords,  poor  system  back-ups,  and 
no  packet  filtering. 

Passwords  are  a  key  element  in  the  utilization  of  the 
Alumni  System.  Unfortunately,  the  use  of  passwords  comes 
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with  the  baggage  of  security  breaches  resulting  from 
compromise  of  those  passwords.  Normally  passwords  are  a 
system's  first  line  of  defense  against  intruders;  this  is 
also  true  in  the  Alumni  System,  so  it  is  imperative  that 
users  understand  the  importance  of  passwords.  To  eliminate 
or  mitigate  the  ability  for  users  to  install  weak 
passwords,  or  passwords  that  are  easy  to  hack,  a  program 
should  be  installed  that  rejects  any  password  change  that 
does  not  meet  the  Alumni  System's  parameters.  These 
parameters  should  contain  requirements  such  as  changing 
passwords  on  at  least  a  semiannual  basis,  ensuring  that 
passwords  are  not  reused,  and  ensuring  that  passwords  are 
made  up  of  more  than  just  alphanumeric  characters.  Efforts 
should  also  be  made  to  ensure  that  passwords  are  adequately 
designed,  so  that  they  will  be  of  the  length  and 
composition  required  to  make  guessing  and  cracking 
difficult.  Users  should  be  given  ample  notice  and  guidance 
on  the  creation  and  utilization  of  passwords.  This  will 
eliminate  difficulties  and  bad  passwords  when  updates  are 
required.  Utilization  of  password-generating  tokens,  such 
as  smart  cards,  is  also  an  option  in  this  system.  This  is 
an  easily  installable  and  very  reliable  option  when 
compared  to  the  traditional  password.  Unfortunately 

because  of  the  costs  involved  and  the  nature  of  this 
system,  this  option  is  neither  feasible  nor  practical.  We 
recommend  that  the  Naval  Postgraduate  School  implement  an 
Alumni  System  that  requires  users  to  be  selective  in  the 
creation  of  their  passwords.  Software  should  be  installed 
that  sets  forth  the  minimum  criteria  required  for  all 
passwords,  and  also  checkpoints  should  be  established  that 
detail  when  new  passwords  should  be  created. 
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How  and  when  to  back  up  data  is  a  potential  data 
integrity  problem  for  the  Alumni  System.  Unfortunately 
when  an  incident  occurs  in  most  organizations,  recovery 
from  the  incident  requires  up  to  date  backups,  which  are 
usually  not  as  current  as  needed.  With  the  Alumni  System, 
backup  policies  and  procedures  should  be  clearly  defined. 
Although  the  exact  size  of  the  potential  system  is  unknown, 
it  is  estimated  that  annually  the  system's  size  and  depth 
will  continue  to  increase  and  will  possibly  approach  the 
gigabyte  range  in  the  future.  Although  much  of  the  data 
housed  within  the  database  would  not  change  very  often, 
because  of  the  number  of  potential  users,  it  is  recommended 
that  backups  be  done  on  a  daily  or  at  least  weekly  basis, 
and  periodic  checks  be  made  at  least  monthly  to  ensure  that 
information  is  being  stored  in  an  adequate  and  usable  form. 
Instituting  this  backup  policy  should  ensure  that  the 
requirements  for  the  Alumni  System  are  met. 

3 .  Firewalls  and  Application  Gateways 

Other  system  requirements  that  need  to  be  addressed  as 
they  relate  to  security  in  the  Alumni  System  are  firewalls 
and  application  gateways.  To  assist  in  helping  to  protect 
the  network  from  attacks,  a  firewall  should  be  installed  in 
the  Alumni  System.  These  hardware  and  software 
combinations  create  narrow  channels  through  which 
information  flow  can  be  tracked  and  controlled.  Firewalls 
can  usually  deter  most  individuals  who  are  trying  to  obtain 
unauthorized  access,  and  at  the  very  least  they  can  warn  of 
an  attack  or  attempted  attack.  The  firewall  should  be 
installed  on  a  dedicated  high  performance  workstation  that 
is  located  outside  of  the  LAN  but  inside  of  the  router  link 
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to  the  Internet.  The  important  thing  to  remember  here  is 
that  all  traffic  should  pass  through  this  firewall.  The 
firewall  that  is  implemented  should  include  packet 
filtering,  which  is  usually  carried  out  by  the  router  as 
data  packets  pass  through  the  router's  interface.  When  the 
router  receives  a  packet,  it  examines  the  IP  destination 
address  in  the  packet  header  and  forwards  the  packet  to  the 


next 

stage 
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of 

defense  between  the 

network  and 

the 

Internet , 

which 

makes  it  relatively  easy  to  filter 

out 

unwanted  traffic  at  the  router. 

In  addition  to  firewalls  that  contain  packet 
filtering,  application  gateways  should  also  be  used  to 
provide  more  security  to  the  Alumni  System.  An  application 
gateway  screens  incoming  data  that  is  based  on  more  than 
just  the  contents  of  a  packet  header.  These  hosts  funnel 
approved  users  to  the  appropriate  application  server.  An 
advantage  of  an  application  gateway  is  that  it  is  usually 
inexpensive  and  less  complex  to  manage.  The  combination  of 
packet  filtering  and  application  gateways  will  provide 
additional  security  to  the  Alumni  System. 

In  addition  to  a  firewall  and  an  application  gateway, 
we  also  recommend  that  a  firewall  monitor  be  used  with  the 
system.  Firewall  monitors  will  be  able  to  detect  potential 
problems  before  they  become  actual  ones.  They  will  be  able 
to  log  application  gateway  usage  and  be  able  to  report  who 
is  using  the  system  and  what  they  are  using  it  for.  These 
monitors  can  also  assist  in  password  security. 

E.  ACCESSIBILITY 
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A  major  concern  of  those  interested  in  the 
construction  of  an  Alumni  database  is  the  issue  of  who 
should  have  access  to  the  system  and  how  much  access  they 
should  have.  After  conducting  an  ample  amount  of  research 
by  way  of  interviews,  surveys,  and  studying  past  systems, 
the  following  access  levels  were  established  for  potential 
system  users.  A  list  of  access  levels  and  explanations  are 
provided  in  Table  15,  and  a  summary  of  recommended  access 
levels  for  each  stakeholder  is  provided  in  Figure  6. 
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Level/Ability /Explanation 

Level  1.  Read  Only.  Although  users  with  this  access  level 
may  utilize  the  system  on  occasion,  the  ability  to  make 
changes  to  the  system  should  not  be  granted.  Having  this 
level  of  access  will  allow  records  to  be  viewed.  Persons 
requiring  this  level  of  access  would  normally  be  office 
clerks . 

Level  2.  Read  and  Modify.  With  this  access  level,  users 
will  be  able  to  perform  all  things  listed  under  Level  1,  as 
well  as  have  the  ability  to  make  modifications  to 
previously  existing  records.  Persons  requiring  this  level 
of  access  are:  school  alumni  (on  their  own  record), 
department  heads,  and  executive  staff,  NPS  Foundation. 

Level  3.  Read,  Modify,  Create,  and  Delete.  With  this 
access  level  nearly  all  functions  of  the  database  can  be 
utilized.  In  addition  to  having  the  access  cited  in 
Level's  1  and  2,  Level  3  users  will  also  have  the  ability 
to  create  and  delete  records.  Because  this  level  involves 
a  high  degree  of  security,  this  access  level  will  be 
restricted.  Persons  requiring  this  level  of  access  are: 
Personnel  of  the  Office  of  the  Registrar,  Alumni  Relations 
Staff 

Level  4.  Total  Access.  With  this  access  level  everything 
available  in  the  system  is  accessible.  In  other  access 
levels  there  are  some  fields  that  will  be  hidden  from  the 
user,  however  this  level  will  contain  no  hidden  fields. 
Those  given  Level  4  access  are  granted  system  administrator 
responsibilities.  Persons  with  this  access  level  will  be 
able  to  grant  or  deny  access  to  potential  users  of  the 
system.  Because  of  the  responsibility  and  security 
involved  with  this  level,  it  will  be  restricted.  Persons 
requiring  this  level  of  access  are:  Alumni  Relations 
Officer,  Executive  Director  of  Institutional  Advancement 
and  Communications 


Table  15.  Access  Description  List 
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MAJOR  STAKEHOLDER  ACCESS 

LEVELS 

Alumni  Relations  Office  (ARO) 

Level 

4 

Alumni  Association 

Level 

2 

Naval  Postgraduate  School  Alumni 

Level 

2 

Naval  Postgraduate  School  Foundation 

Level 

2 

Office  of  the  Registrar 

Level 

3 

Department  of  International  Programs 

Level 

2 

Naval  Postgraduate  School  Departments 

Level 

1  &  2 

Student  Services 

Level 

2 

Figure  6.  Major  Stakeholder  Access  Levels 

F.  INTERACTION  WITH  OTHER  NPS  SYSTEMS 

Another  key  issue  that  must  be  addressed  is  how  the 
Alumni  System  will  interact  with  current  Naval  Postgraduate 
School  systems.  To  ensure  that  effective  and  efficient 
integration  is  achieved,  the  proposed  Harris  system  will 
utilize  its  Data  Exchange  System  to  transfer  data  between 
its  Online  Directory  and  the  Naval  Postgraduate  School's 
databases.  Clear  and  regular  communication  between  these 
entities  is  necessary  to  ensure  that  a  complete  and 
accurate  transfer  of  data  is  obtained.  Prior  to  submitting 
the  initial  data  file  to  Harris,  several  parameters  will  be 
defined  by  the  Naval  Postgraduate  School  to  ensure  that  the 
data  requirements  are  understood.  The  discussions  will 
define  the  plan  for  the  Online  Directory  Database  plus 
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format  the  initial  file  and  subsequent  files  transferred 
to,  and  obtained  from,  Harris.  Once  the  submission  is 
understood  and  accepted,  data  exchange  will  begin.  As 
users  make  updates  to  the  system,  a  daily  report  will  be 
created,  maintained,  and  provided  to  the  Naval  Postgraduate 
School.  All  data  will  be  exchanged  through  a  Harris  secure 
file  transfer  site  and  will  be  made  available  to  the 
school.  To  ensure  that  adequate  security  is  maintained, 
the  Online  Directory  will  be  made  available  only  to  those 
users  who  register  for  access  to  the  system.  The 
registration  process  requires  user  authentication  that  will 
attempt  to  prohibit  unauthorized  usage  and  viewing.  During 
the  authentication  process,  alumni  will  be  required  to 
search  the  database  for  their  profile,  and  once  their 
profile  has  been  found,  they  will  be  required  to  enter  a 
unique  security  code  identifier.  It  is  recommended  that 
the  name  and  the  last  four  digits  of  the  social  security 
number  or  international  identification  number  be  used. 
Only  after  this  is  verified  will  users  be  allowed  to 
establish  IDs  and  passwords  in  the  system  for  future  usage. 
Harris  will  physically  maintain  the  Online  Directory 
Database  on  a  secure  server,  while  NPS  representatives  will 
be  responsible  for  maintaining  the  content  of  the  database 
through  data  transfers. 

An  example  of  how  the  alumni  system  will  interact  with 
other  Naval  Postgraduate  School  systems  is  depicted  in  an 
example  of  how  the  school  will  conduct  its  Schieffelin 
Award  process  for  the  school's  best  teacher.  Annually  the 
school  solicits  nominations  and  input  from  its  alumni  and 
other  participants  regarding  potential  recipients  of  its 
best  teacher  award.  Currently  this  process  is  not  very  far 
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reaching  because  many  of  the  school's  alumni  are  not 
contacted.  The  proposed  system  however,  will  greatly 
affect  this  process.  At  the  onset  of  the  award  process, 
profiles  of  potential  nominees  (name,  title,  department, 
accomplishments/research,  etc...)  will  be  compiled  from 
PYTHON  and  stored  in  a  PYTHON  table  that  is  linked  to  the 
alumni  database.  A  Naval  Postgraduate  School  staffer  would 
then  specify  a  target  audience  based  upon  Online  Directory 
fields.  Once  this  information  is  validated,  the  staffer 
would  then  utilize  a  broadcast  email  application  located 
within  the  alumni  database  to  publish  the  information  to 
alumni.  Within  the  email,  each  respondent  will  be  directed 
to  an  online  ballot,  wherein  they  will  be  requested  to  vote 
for  faculty  members  who  were  their  instructors  when  they 
attended  NPS.  The  ballots  and  instructors  are  linked 
(transparently  to  voters)  to  the  PYTHON  database,  which 
collects  and  tabulates  statistics  from  the  ballots  to  be 
presented  to  the  Schieffelin  Award  Committee.  An  expanded 
essential  use  case  for  this  process  is  provided  in  the 
appendix  in  Table  28. 

F.  RESPONSIBILITY 

Along  with  having  accessibility  to  the  system,  users 
will  also  be  required  to  perform  several  tasks  to  assist  in 
the  accuracy  of  the  system.  A  brief  list  of  user 
responsibilities  to  the  system  is  listed  below. 

1 .  Level  1 

Because  of  the  limited  capabilities  involved  with  this 
access  level,  there  are  limited  responsibilities  as  well. 
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Users  with  Level  1  access  are  required  to  point  out 
informational  inaccuracies  when  they  are  noted  in  the 
system.  They  should  also  indicate  system  problems  that  are 
experienced  during  normal  use. 

2 .  Level  2 

As  with  access  criteria,  the  responsibilities  of  the 
previous  level  will  be  included  in  the  next  level's 
responsibility,  so  in  addition  to  the  responsibilities  of 
Level  1  users,  which  is  to  ensure  the  accuracy  of  the 
system.  Level  2  users  are  required  to  enter  only  accurate 
and  verified  information  into  the  system.  In  the  event 
that  an  error  is  discovered,  persons  with  this  level  of 
access  are  required  to  correct  the  information  or  forward 
it  to  the  next  highest  level.  Because  many  of  the  school's 
alumni  will  be  granted  this  level  of  responsibility  it  is 
important  that  accurate  and  updated  information  be 
emphasized.  Because  of  the  large  number  of  potential 
records  that  could  be  stored  in  the  Alumni  System,  level  2 
users  must  understand  that  their  involvement  and  upkeep  of 
the  system  is  vital  to  its  existence. 

3 .  Level  3 

Level  3  users  have  a  critical  responsibility  in  the 
Alumni  system.  These  are  the  users  that  are  responsible 
for  the  daily  input  and  upkeep  of  new  information  being 
entered  into  the  system.  Level  3  responsibilities  include 
all  the  responsibilities  of  the  previous  two  levels  plus 
the  responsibility  of  verifying  and  validating  all  data 
prior  to  creating  a  record  in  the  system.  Also  because  of 
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the  ability  to  delete  records.  Level  3  users  are  required 
to  ensure  that  records  that  have  been  marked  for  deletion 
are  no  longer  required.  Level  3  users  will  play  a  big  part 
in  the  overall  success  of  the  Alumni  System.  Once  the 
database  is  populated,  it  is  their  responsibility  to  check 
records  and  ensure  that  they  are  valid,  and  in  the  event 
that  they  are  not,  they  must  correct  or  delete  them.  Level 
3  persons  should  realize  that  the  system  will  only  be  as 
good  as  they  make  it . 

4 .  Level  4 

In  addition  to  the  responsibilities  of  all  the 
previous  levels.  Level  4  is  also  responsible  for  adequately 
maintaining  the  system  for  utilization  by  authorized  users. 
These  users  are  required  to  make  system  modifications  when 
needed,  and  they  act  as  the  direct  links  to  maintenance 
personnel  if  a  situation  occurs  that  cannot  be  fixed  by  the 
Level  4  user.  Level  4  users  will  ensure  that  the  system  is 
operational  and  ready  for  use  on  a  daily  basis.  Level  4 
users  will  monitor  the  usage  of  the  other  users  to  ensure 
that  they  are  adhering  to  their  requirements  and 
responsibilities  to  the  system. 

G .  SUMMARY 

In  order  to  ensure  that  the  requirement  analysis  being 
conducted  for  the  alumni  system  was  thorough,  several 
issues  had  to  be  confronted,  and  throughout  this  chapter  we 
have  attempted  to  do  that.  The  main  stakeholders  of  the 
system  were  identified  and  their  interactions  with  the 
system,  as  well  as,  the  average  user  were  detailed  in  use 
cases.  A  database  schema  was  presented  to  provide  a 
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foundation  for  how  the  database  will  look  and  the  possible 
relationships  that  it  may  contain.  Major  concerns  like 
security,  interaction  with  preexisting  systems,  user 
access,  and  user  responsibility  were  also  detailed 
throughout  the  chapter.  In  addition  to  identifying  the 
major  concerns,  possible  remedies  and  recommendations  were 
also  provided  that  could  alleviate  or  even  eliminate  many 
of  those  lingering  questions  that  still  exist  about  the 
Naval  Postgraduate  Alumni  Database.  Results  and 
recommendations  were  provided  to  ease  the  fears  and 
concerns  of  decision  makers.  This  was  done  to  move  them 
closer  to  deciding  in  the  favor  of  approving  funding  for  a 
more  productive  system. 
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V. 


CONCLUSION 


We  have  thoroughly  evaluated  the  Naval  Postgraduate 
School's  Alumni  System  as  part  of  a  process  to  develop  a 
more  effective  and  efficient  one.  To  facilitate  that 
effort  we  began  by  determining  the  central  and  most 
important  questions  and  requirements  for  having  an 
effective  system.  We  looked  at  reasons  why  those  specific 
requirements  are  important  to  the  alumni  system,  and  we 
established  guides  and  methods  for  determining  how  to 
answer  those  questions  and  fill  those  system  requirements. 
To  ensure  that  we  did  not  make  the  same  mistakes  of 
previous  attempts  at  designing  an  effective  system,  we 
studied  the  history  of  past  alumni  systems.  Throughout 
that  process,  we  highlighted  the  problems  and  successes  of 
those  flawed  systems,  and  established  an  adequate  structure 
for  future  systems.  Once  we  understood  the  possible 
problems  that  a  new  system  could  experience  and  its 
requirements,  we  compared  and  analyzed  the  costs  and 
benefits  of  the  options  available  to  the  Naval  Postgraduate 
School.  The  analysis  led  to  the  choice  of  Harris  C. 
Publishing  Incorporated  as  the  most  desirable  of  all  the 
alternatives.  Overall  total  cost  and  net  present  value 
were  among  the  chief  factors  that  led  to  this 
recommendation . 

In  addition  to  determining  the  most  desirable  system, 
identification  of  the  major  stakeholders  in  the  system  had 
to  be  accomplished .  A  database  schema  was  created  to 
provide  a  glimpse  of  the  database's  structure. 
Additionally,  tables,  relationships,  domains,  and  data 
requirements  were  provided  to  assist  in  establishing  a 
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foundation  for  future  databases.  Use  cases  were  designed 
that  detail  the  step-by-step  process  of  user-system 
interaction,  and  provide  additional  assistance  in 
determining  and  understanding  the  requirements  of  the 

system.  Major  security  issues  were  addressed  that  identify 
the  potential  problems,  and  possible  remedies  to  those 
issues  as  well.  Finally,  user  access  and  responsibility 
were  established  to  document  the  standards  that  each 

potential  user  will  have  to  maintain  to  ensure  that  the 
system  is  successful. 

We  have  developed  a  set  of  high-level  requirements 
that  any  vendor  or  developer  can  use  as  a  basis  for 

developing  an  alumni  system.  Our  efforts  have  generated 
what  we  believe  is  an  effective  tool  that,  if  used 

properly,  will  assist  the  Naval  Postgraduate  School  in 
developing  an  alumni  system  that  is  robust,  accurate,  and 

effective . 
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VI .  APPENDIX 
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Figure  7 . 


Database  Schema 


B. 


BASIC  FUNCTIONS 


Ref .# /Category  Functions 

Rl. 1/Evident  Customer  must  register  in  the  system  before  it  can  be 

utilized 


Rl. 2/Evident  Customer  must  login  with  an  appropriate  social 

security  number/identif ication  number  and  password  in 
order  to  use  the  system 

Rl. 3/Hidden  Verification  of  passwords  and  social 

security/identification  numbers  before  allowing 
access  to  information 


Rl. 4/Evident  Allow  for  the  creation  of  new  records  to  the  system 

Rl. 5/Evident  Allow  for  the  deletion  of  unwanted  records 


Rl. 6/Evident  Allow  individual  and  group  modifications  to  be  made 

to  previously  existing  records 


Rl. 7/Hidden  Provide  an  adequate  storage  mechanism 

Rl. 8/Evident  Provide  a  platform  where  information  and  ideas  can  be 

exchanged  amongst  the  system' s  users 

Rl. 9/Hidden  Run  queries  for  requested  information 


Table  16.  Use  Case  Basic  Functions 
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C.  BASIC  USE  CASES 

1.  Use  Case:  Login 


SECTION:  MAIN 


Use  Case: 
Actors: 
Purpose: 
Overview: 


Type: 


LOGIN 

All  System  Users/Customers 
Prepare  the  alumni  system  for  use 

A  customer/user  arrives  at  a  computer  terminal  to  access  the 
alumni  system.  The  user  inputs  and/or  retrieves  the  required 
information.  At  completion,  the  user  leaves  with  the  generated 
information. 

Primary  and  essential 


Cross  References:  Rl.l,  R1.2,  R1.3 


Typical  Course  of  Events: 


Actor  Action 


System  Response 


1 .  This  use  case  begins  when  the 
customer  arrives  at  a  computer  terminal 
to  input  or  retrieve  information. 


2.  The  user  logs  into  the  system  utilizing  a  multi-character 
password. 

3.  Acknowledges  and  verifies  password. 
Allows  user  access  to  the  system’s 
data. 

4.  User  proceeds  to  the  main  menu  of  the 
available  system  functions. 


Alternative  Courses: 

Line  2:  Invalid  password  entered.  Indicate  error  upon  three  invalid  attempts,  exit  the 
system. 


Table  17  . 


Use  Case:  Login 
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2. 


Use  Case :  Modify  A  Record 


SECTION:  MAIN 


Use  Case:  MODIFY  AN  ALUMNI  RECORD 


Actors: 


Purpose: 

Overview: 


Type: 


Customers:  Registrar,  Alumni  Relations  Office,  School  Alumni, 
NPS  Foundation,  NPS  Departments 

To  update  preexisting  data  in  the  alumni  database 

A  customer  arrives  at  a  computer  terminal  to  modify  a  record  or 
records  that  already  exist  in  the  system.  The  customer  inputs  the 
modifying  infonnation.  The  system  records  and  saves  the 
information.  Upon  completion  the  user  exits  the  system. 

Primary  and  essential 


Cross  References:  Rl.l,  R1.2,  R1.3,  R1.6,  R1.7 


Use  Cases:  Customers  must  have  completed  the  login  use  case. 

Typical  Course  of  Events: 

Actor  Action  System  Response 


1 .  User  selects  the  modify  a  record 
option  from  the  main  menu. 


4.  User  inputs  the  required  social 
security/identification  number  into 
the  system. 


2.  System  asks  if  it  is  this  an 
individual  or  group  modification. 

3.  System  prompts  user  to  enter  social 
security  number  or  an  international 
alumni  identification  number. 


5.  System  summons  the  appropriate 
record. 
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Typical  Course  of  Events  Continued: 


Actor  Action  System  Response 

6.  User  verifies  and  makes  adjustments 

to  the  alumni  record  and  saves  the  infonnation. 

7.  System  saves  the  information  into 
the  database. 

9.  User  clicks  exit  to  leave  the 
modification  screen. 

10.  Return  user  to  the  main  menu. 


Alternative  Courses: 

8.  User  inputs  another  valid  social  security/identification  number. 


Table  18. 


Use  Case:  Modify  a  Record 
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3. 


Use  Case:  Delete  A  Record 


SECTION:  MAIN 


Use  Case:  DELETE  AN  ALUMNI  RECORD 


Actors: 

Purpose: 

Overview: 


Type: 


Customers:  Registrar,  Alumni  Relations  Office 

To  delete  a  record  that  is  resident  in  the  alumni  database 

A  customer  arrives  at  a  computer  terminal  to  remove  a  preexisting 
alumni  record  from  the  database.  The  customer  recalls  the  record 
and  removes  it  from  the  system.  The  system  records  the  update. 
Upon  completion  the  customer  exits  the  system. 

Primary  and  essential 


Cross  References:  Rl.l,  R1.2,  R1.3,  R1.5,  R1.7 


Use  Cases:  Customers  must  have  completed  the  login  use  case. 

Typical  Course  of  Events: 

Actor  Action  System  Response 

1 .  User  selects  the  delete  a  record  option 
from  the  main  menu. 


2.  Delete  record  screen  appears  and 
prompts  user  to  enter  social 
security  number  or  identification 
number  for  international  alumni. 

3.  User  inputs  the  required  social 
security/identification  number  into 
the  system  and  clicks  delete  to  remove 
the  record. 

4.  System  summons  the  appropriate 
record  and  ensures  the  user  wants 
to  delete  the  record. 


5.  User  verifies  and  confirms  deletion. 
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Typical  Course  of  Events  Continued: 

Actor  Action  System  Response 

7.  System  deletes  the  record,  and 
saves  the  information  into  the 
database. 

8.  System  prompts  user  to  enter  a 
new  record. 

9.  User  clicks  exit  to  leave  the  deletion 
screen. 

10.  Return  User  to  the  main  menu. 


Table  19.  Use  Case:  Delete  a  Record 
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4. 


Use  Case:  Create  A  Record 


SECTION:  MAIN 

Use  Case:  CREATE  AN  ALUMNI  RECORD 


Actors:  Customers:  Registrar,  Alumni  Relations  Office,  School  Alumni 

Purpose:  To  generate  a  new  record  that  will  be  maintained  in  the  alumni 

database 


Overview:  A  customer  arrives  at  a  computer  terminal  to  create  a  new  record  in 

the  system.  The  customer  inputs  the  infonnation.  The  system 
verities  the  information  and  records  it.  Upon  completion,  the 
customer  exits  the  system. 

Type:  Primary  and  essential 


Cross  References:  Rl.l,  R1.2,  R1.3,  R1.4 


Use  Cases:  Customers  must  have  completed  the  login  use  case 


Typical  Course  of  Events: 


Actor  Action 


System  Response 


1 .  User  selects  the  create  a  record  option 
from  the  main  menu. 


3.  User  inputs  the  information  on  the  new 
record. 


2.  New  record  information  screen 
appears  requesting  both  mandatory 
and  optional  information. 

4.  System  accepts  new  record 

information  and  saves  the  record  in 
the  system. 


7.  User  clicks  exit  to  leave  the  creation 
screen. 

8.  Return  user  to  the  main  menu  screen. 

Alternative  Courses: 

5.  System  rejects  record  and  prompts  user  for  more  information. 

6.  System  rejects  record  because  the  record  is  already  present  in  the  system. 


Table  20.  Use  Case:  Create  a  Record 
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5. 


Use  Case:  Generate  Reports 


SECTION:  MAIN 


Use  Case:  GENERATE  REPORTS 


Actors: 

Purpose: 


Overview: 


Type: 


Customers:  Registrar,  Alumni  Relations  Office,  NPS  Departments 

To  generate  and  print  relevant  alumni  reports  utilizing  data 
obtained  and  compiled  in  the  alumni  database 

A  customer  arrives  at  a  computer  terminal  to  generate  reports  from 
the  alumni  system.  The  customer  selects  the  topics  and 
information  required.  The  system  acknowledges  the  information 
requested  and  generates  the  relevant  report(s).  Upon  completion, 
the  customer  exits  the  system  and  leaves  with  the  reports. 

Primary  and  essential 


Cross  References:  Rl.l,  R1.2,  R1.3,  R1.9 


Use  Cases:  Customer  must  have  completed  the  login  use  case 

Typical  Course  of  Events: 


Actor  Action 

1 .  User  selects  the  print  reports  option 
from  the  main  menu. 


3.  User  clicks  type  of  report  and  selects 
the  data  to  be  included  in  the  report. 


5.  User  clicks  exit  to  leave  the  print 
reports  screen. 


System  Response 


2.  Print  reports  screen  appears 
requesting  type  of  report  to  be 
generated. 


4.  System  accepts  the  selections  and 
generates  the  required  report. 


6.  Return  user  to  the  main  menu. 


Table  21.  Use  Case:  Generate  Reports 
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6. 


Use  Case :  Conduct  A  Survey 


SECTION:  MAIN 


Use  Case: 

Actors: 

Purpose: 


Overview: 


Type: 


CONDUCT  A  SURVEY/QUESTIONNAIRE 

Customers:  Registrar,  Alumni  Relations  Office,  NPS  Departments 

To  solicit  information  from  NPS  Alumni  regarding  a  specified 
topic  or  group  of  topics 

A  customer  arrives  at  a  computer  tenninal  to  solicit  responses  to  a 
survey/questionnaire  that  is  being  conducted.  The  customer 
generates  a  list  of  persons  to  receive  the  survey  through  the 
utilization  of  the  alumni  database.  The  system  acknowledges  the 
request  and  generates  a  list  of  email  accounts,  and  addresses  based 
on  specified  criteria.  The  customer  utilizes  this  infonnation  to 
conduct  a  survey. 

Secondary  and  essential 


Cross  References:  Rl.l,  R1.2,  R1.3,  R1.9 


Use  Cases:  Customers  must  have  completed  the  login  use  case 

Typical  Course  of  Events: 

Actor  Action  System  Response 

1 .  User  selects  the  conduct  a  survey 
option  from  the  main  menu. 

2.  Conduct  a  survey  screen  appears 
prompting  user  to  enter  survey 
criteria 

3.  User  inputs  the  survey  criteria. 

4.  System  accepts  the  criteria  and 
generates  the  survey  based  on  the 
criteria  selected. 


5.  User  clicks  exit  to  leave  the  conduct  a 
survey  screen. 


6.  Return  user  to  the  main  menu. 


Table  22.  Use  Case:  Conduct  s  Survey 
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Figure  9. 


E. 


QUERY  LIST 

Information 


obtai 


interviews,  surveys,  anc 
list  of  queries  that 


system.  The  list  is  pro\ 


QUERY 

Alumni  by  class  year 

Alumni  by  country 

Alumni  by  curricula 

Alumni  by  city 

Last  Name  query 

Graduation  date  query 

Alumni  by  race 
Alumni  by  military 

Email  address  query 

Address  &  state  query 


Figure  1 0 . 


DESCRIPTION 

Provides  a  list  of  alumni  by  class 
year 

Provides  a  list  of  alumni  by 
country  of  origin 

Provides  a  list  of  alumni  by 
curricula  studied  at  NPS 

Provides  a  list  of  alumni  by  city 
of  current  residence 

Provides  a  list  of  alumni  by  last 
name 

Provides  a  list  of  alumni  by  date 
that  they  graduated 

Provides  a  list  of  alumnus  by  race 

Provides  a  list  of  alumnus  by 
military  branch 

Provides  a  list  of  alumni  and 
their  email  addresses 

Provides  a  list  of  alumni  by 
current  address  and  state 


Query  List 
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F .  REPORT  LIST 

Information  gathered  from  interviews  with  key 
representatives,  survey  results,  and  other  research  aided 
in  compiling  a  list  of  reports  that  could  be  required  once 
a  new  or  modified  system  is  completed.  This  list  is 
provided  in  Figure  10. 


REPORT 


Alumni  by  class  year 


Alumni  by  country 


Alumni  by  curricula 


Alumni  by  city 


Last  Name  query 


DESCRIPTION 

Provides  a  list  of  alumni  by  class 
year 

Provides  a  list  of  alumni  by 
country  of  origin 

Provides  a  list  of  alumni  by 
curricula  studied  at  NPS 

Provides  a  list  of  alumni  by  city 
of  current  residence 

Provides  a  list  of  alumni  by  last 
name 


Graduation  date  query  Provides  a  list  of  alumni  by  date 

that  they  graduated 


Alumnus  by  race 
Alumnus  by  military 


Provides  a  list  of  alumnus  by  race 

Provides  a  list  of  alumnus  by 
military  branch 


Alumni  by  email  address  Provides  a  list  of  alumni  and 

their  email  addresses 

Alumni  by  address&state  Provides  a  list  of  alumni  by 

current  address  and  state 


Figure  1 1 . 


Reports  List 
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G.  ADDITIONAL  USE  CASES 

1 .  Use  Case :  Alumni  by  Graduation  Date  Report 


SECTION:  MAIN 


Use  Case:  GENERATE  ALUMNI  BY  GRANDUATION  DATE  REPORT 

Actors:  Customer:  Student  Services 


Purpose: 


Overview: 


Type: 


To  generate  a  report  that  lists  all  NPS  alumni  and  the  date  that  they 
graduated  from  the  school. 

A  customer  arrives  at  a  computer  terminal  to  generate  reports  from 
the  alumni  system.  The  customer  selects  the  report  parameters. 

The  system  acknowledges  the  information  requested  and  generates 
the  relevant  report(s).  Upon  completion,  the  customer  exits  the 
system  and  leaves  with  the  reports. 

Primary  and  essential 


Cross  References:  Rl.l,  R1.2,  R1.3,  R1.9 


Use  Cases:  Customer  must  have  completed  the  login  use  case 


Typical  Course  of  Events: 

Actor  Action 

1 .  User  selects  the  print  reports  option 
from  the  main  menu. 


3.  User  selects  the  required  report  from 
the  options  and  enters  additional 
parameters  that  may  be  required. 


5.  User  clicks  exit  to  leave  the  print 
reports  screen. 


System  Response 


2.  Reports  screen  appears,  prompting 
user  to  select  an  option. 


4.  System  accepts  the  selections  and 
generates  the  required  report. 


6.  Return  user  to  the  main  menu. 


Use  Case:  Alumni  by  Graduation  Date 
Report 
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Table  23. 


2. 


Use  Case :  Alumni  by  Email  Report 


SECTION:  MAIN 

Use  Case:  GENERATE  ALUMNI  BY  EMAIL  AND  ADDRESS  REPORT 

Actors:  Customer:  Alumni  Relations  Office 

Purpose:  To  generate  a  report  that  lists  all  NPS  alumni,  their  email  and 

current  address 


Overview:  A  customer  arrives  at  a  computer  terminal  to  generate  reports  from 

the  alumni  system.  The  customer  selects  the  report  parameters. 

The  system  acknowledges  the  information  requested  and  generates 
the  relevant  report(s).  Upon  completion,  the  customer  exits  the 
system  and  leaves  with  the  reports. 

Type:  Primary  and  essential 

Cross  References:  Rl.l,  R1.2,  R1.3,  R1.9 

Use  Cases:  Customer  must  have  completed  the  login  use  case 

Typical  Course  of  Events: 

Actor  Action  System  Response 

1 .  User  selects  the  print  reports  option 
from  the  main  menu. 

2.  Reports  screen  appears,  prompting 
user  to  select  an  option. 

3.  User  selects  the  required  report  from 
the  options  and  enters  additional 
parameters  that  may  be  required. 

4.  System  accepts  the  selections  and 
generates  the  required  report. 


5.  User  clicks  exit  to  leave  the  print 
reports  screen. 


6.  Return  user  to  the  main  menu. 


Table  24.  Use  Case:  Alumni  by  Email  Address 

Report 
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3. 


Use  Case :  Alumni  by  Curricula  Report 


SECTION:  MAIN 

Use  Case:  GENERATE  ALUMNI  BY  CURRICULA  REPORT 

Actors:  Customer:  NPS  Departments 

Purpose:  To  generate  a  report  that  lists  all  NPS  alumni  and  the  curricula  that 

they  studied  while  attending  the  school 

Overview:  A  customer  arrives  at  a  computer  terminal  to  generate  reports  from 

the  alumni  system.  The  customer  selects  the  report  parameters. 

The  system  acknowledges  the  information  requested  and  generates 
the  relevant  report(s).  Upon  completion,  the  customer  exits  the 
system  and  leaves  with  the  reports. 

Type:  Primary  and  essential 

Cross  References:  Rl.l,  R1.2,  R1.3,  R1.9 

Use  Cases:  Customer  must  have  completed  the  login  use  case 

Typical  Course  of  Events: 

Actor  Action  System  Response 

1 .  User  selects  the  print  reports  option 
from  the  main  menu. 

2.  Reports  screen  appears,  prompting 
user  to  select  an  option. 

3.  User  selects  the  required  report  from 
the  options  and  enters  additional 
parameters  that  may  be  required. 

4.  System  accepts  the  selections  and 
generates  the  required  report. 

5.  User  clicks  exit  to  leave  the  print 
reports  screen. 

6.  Return  user  to  the  main  menu. 


Table  25.  Use  Case:  Alumni  by  Curricula  Report 
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4 .  Use  Case :  Alumni  by  Country  Report 
SECTION:  MAIN 

Use  Case:  GENERATE  ALUMNI  BY  COUNTRY  REPORT 

Actors:  Customer:  Department  of  International  Programs 

Purpose:  To  generate  a  report  that  lists  all  NPS  alumni  and  their  country  of 

origin 

Overview:  A  customer  arrives  at  a  computer  terminal  to  generate  reports  from 

the  alumni  system.  The  customer  selects  the  report  parameters. 

The  system  acknowledges  the  information  requested  and  generates 
the  relevant  report(s).  Upon  completion,  the  customer  exits  the 
system  and  leaves  with  the  reports. 

Type:  Primary  and  essential 

Cross  References:  Rl.l,  R1.2,  R1.3,  R1.9 

Use  Cases:  Customer  must  have  completed  the  login  use  case 

Typical  Course  of  Events: 

Actor  Action  System  Response 

1 .  User  selects  the  print  reports  option 
from  the  main  menu. 

2.  Reports  screen  appears,  prompting 
user  to  select  an  option. 

3.  User  selects  the  required  report  from 
the  options  and  enters  additional 
parameters  that  may  be  required. 

4.  System  accepts  the  selections  and 
generates  the  required  report. 

5.  User  clicks  exit  to  leave  the  print 
reports  screen. 

6.  Return  user  to  the  main  menu. 

Table  26.  Use  Case:  Alumni  by  Country  Report 
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5.  Use  Case:  Schieffelin  Award 

SECTION:  MAIN 

Use  Case:  RECEIVE  NOMINATIONS  FOR  SCHIEFFELIN  AWARD 

Actors:  Customers:  Registrar,  Alumni  Relations  Office,  NPS  Foundation, 

NPS  Departments,  NPS  Alumni 

Purpose:  To  solicit  nominations  for  the  Naval  Postgraduate  School 

Schieffelin  Award 

Overview:  Customers  arrive  at  computer  terminals  to  both  solicit  and  provide 

nominations  for  the  NPS  Schieffelin  Award.  The  initiating 
customer  generates  a  survey,  and  the  responding  customer  inputs  a 
nomination  into  the  system.  The  system  compiles  the  list  of 
nominations  and  generates  a  report.  The  initiating  customer 
utilizes  this  information  to  recommend  an  award  recipient. 

Type:  Secondary  and  essential 

Cross  References:  Rl.l,  R1.2,  R1.3,  R1.7,  R1.8,  R1.9 

Use  Cases:  Customers  must  have  completed  the  login  use  case 

Typical  Course  of  Events: 

Actor  Action  System  Response 

1 .  Initiating  customer  accesses  the  broadcast 
Email  application  from  the  main  menu. 

2.  The  broadcast  email  screen 
appears  prompting  the  initiating 
customer  to  enter  survey  criteria. 

3.  Initiating  customer  selects  a  target  audience. 

4.  System  accepts  the  criteria. 

5.  Initiating  customer  provides  detailed 

instructions  and  other  pertinent  information 
in  the  broadcast  interface. 

6.  System  prompts  user  to  select 
either  single  (text,  html,  etc...)or 
dual  (combination)  message 
mode 
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Typical  Course  of  Events  Continued: 


Actor  Action 


System  Response 

7.  The  system  acknowledges  the 
customer’s  selections  and 
provides  the  requested  message 
form. 


8.  Initiating  customer  reviews  the  message 
created  and  submits  the  broadcast  to  all 
potentially  responding  customers 

9.  The  message  is  broadcasted  to 
alumni  per  the  selected  criteria. 

10.  Potential  responding  customers  receive  the 
broadcasted  message.  Customers  follow  the 
instructions  provided,  complete,  and  submit 
the  survey. 

1 1 .  The  system  receives  the 
submission 


12.  The  initiating  customer  selects  the  option 
to  compile  the  submission. 


13.  System  compiles  and  tallies  all 
submissions  received 


14.  Initiating  customer  requests  report  of  compiled 
submission 


15.  System  generates  the  report. 


16.  Initiating  customer  receives  the  report  and 
clicks  end  to  exit  the  report  menu. 


17.  Return  user  to  the  main  menu. 


Table  27  . 


Use  Case:  Schieffelin  Award 
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